Perform SWT-natives build as part of the master/verification build

[HannesWell]

First part of #513

The build procedure is based on the configurations in https://ci.eclipse.org/releng/view/SWT%20Natives/
Namely these are:

• https://ci.eclipse.org/releng/job/SWT-Increment_if_needed/configure
• https://ci.eclipse.org/releng/job/cocoa_aarch64/configure
• https://ci.eclipse.org/releng/job/cocoa_x86_64/configure
• https://ci.eclipse.org/releng/job/gtk_linux_aarch64/configure
• https://ci.eclipse.org/releng/job/gtk_linux_ppc64le/configure
• https://ci.eclipse.org/releng/job/gtk_linux_x86_64/configure
• https://ci.eclipse.org/releng/job/win32_x86_64/configure

The steps of all those jobs are now perform in the Jenkins-build of this o.e.swt repo and thus makes all the mentioned jobs obsolete. This also makes building the swt-binaries as part of the I-builds obsolete. It has also the advantage that one can get immediate feedback in verification-builds for changes that affect the SWT-binaries.

[github-actions]

Test Results

     303 files       303 suites   5m 49s ⏱️
  4 048 tests   4 035 ✔️   8 💤 4 ❌ 1 🔥
12 071 runs  11 995 ✔️ 70 💤 5 ❌ 1 🔥

For more details on these failures and errors, see this check.

Results for commit a78d1fe.

♻️ This comment has been updated with latest results.

[HannesWell]

Besides that it looks like the project is not prepared to push to the swt(-natives)-repo:

  + git push origin HEAD:refs/heads/testSWTNativesInPipeline
  [email protected]: Permission denied (publickey).
  fatal: Could not read from remote repository.
  
  Please make sure you have the correct access rights
  and the repository exists.

This was because I oversaw the SSH-agent setup in the existing/old SWT-Increment_if_needed job. After adding a sshagent(['github-bot-ssh']) step, the pipeline now successfully pushes to the swt and swt.binaries repo.

You can see the results here:

• https://github.com/eclipse-platform/eclipse.platform.swt/tree/testSWTNativesInPipeline
• https://github.com/eclipse-platform/eclipse.platform.swt.binaries/tree/testSWTNativesInPipeline

But while testing pushing I noticed that the automated natives-build respectively the automated enforced-qualifier commits will trigger another round of automated updates, which likely leads to an infinite update-cycle.
So I will need to think about a mechanism to detect if the latest commit was created by the automated SWT-update.
Probably based on the commit message and committer/author.
On the long run, the enforced qualifier updates should not be necessary at all, which then hopefully makes this mechanism obsolete. But I don't want to change that in this PR.

[fredg02]

Looks like the initial error is fixed, but there seems to be another one on the new macos-x86_64 node

That error should be fixed as well now. It required to update the MacOS Developer Command Line Tools from version 12.5 to 13.2 (with softwareupdate -i "Command Line Tools for Xcode-13.2") .

[HannesWell]

Looks like the initial error is fixed, but there seems to be another one on the new macos-x86_64 node

That error should be fixed as well now. It required to update the MacOS Developer Command Line Tools from version 12.5 to 13.2 (with softwareupdate -i "Command Line Tools for Xcode-13.2") .

Great. Thank you! I can confirm that the mac build is now working for both architectures.

But while testing pushing I noticed that the automated natives-build respectively the automated enforced-qualifier commits will trigger another round of automated updates, which likely leads to an infinite update-cycle.
So I will need to think about a mechanism to detect if the latest commit was created by the automated SWT-update.
Probably based on the commit message and committer/author.

I prevent such self-loop now by performing a check if the HEAD commit was committed by the Eclipse Releng Bot. In that case the build simply aborts, as you can see for example in https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/testSWTNativesInPipeline/8/console.
This way and endless loop of builds where the automated update triggers a new build immediately which again triggers a new build is prevented.

So I think this is ready now. You can see the results here:

• https://github.com/eclipse-platform/eclipse.platform.swt/tree/testSWTNativesInPipeline
• https://github.com/eclipse-platform/eclipse.platform.swt.binaries/tree/testSWTNativesInPipeline

The only thing to do, before this can be submitted is to remove the last commit (which was only used to test pushing) and to squash the others.

@mickaelistria, @akurtakov or anybody else: Do you want to review this?
I assume you prefer to wait until the master branch opens for the 2023-06 before submitting this?

[mickaelistria]

@mickaelistria, @akurtakov or anybody else: Do you want to review this?

I've personally lost track (again) on this topic and don't intend to refocus on it soon enough to give a helpful review, sorry.

I assume you prefer to wait until the master branch opens for the 2023-06 before submitting this?

Yes please.

[HannesWell]

@mickaelistria, @akurtakov or anybody else: Do you want to review this?

I've personally lost track (again) on this topic and don't intend to refocus on it soon enough to give a helpful review, sorry.

OK, no problem. I did some more testing (changes and a few more adjust and I'm now relatively confident that this change is fine as it is.
Therefore I suggest to submit this as soon as the master opens again and if anyone encounters problems I'll try to fix them as soon as possible.
Of course everybody interested is invited to review this PR until then.

[HannesWell]

Since the master branch is now open I plan to submit this PR tomorrow evening, unless anybody objects.

[HannesWell]

All tests on Jenkins are green and the GH-workflow failures are the same like on previous master builds. Therefore I believe they are unrelated.
So this is ready for submission now; Merging.
I will monitor the next master branch build to verify that it behaves as expected.

Thanks to everyone that helped to make this happen, especially @fredg02!

[HannesWell]

So the build succeeded as expected in https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/24/ 🎉
And as intended the subsequent master-branch triggered from the push of the updated timestamps was aborted to prevent an endless build loop: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/25/

Unfortunately we will now see aborted builds in the master queue, but I didn't found an elegant way to suppress. Maybe it would be possible with adjusting the Jenkins/GH-hook configuration. But I don't have access to that.

The build procedure is based on the configurations in https://ci.eclipse.org/releng/view/SWT%20Natives/ Namely these are:

* https://ci.eclipse.org/releng/job/SWT-Increment_if_needed/configure

* https://ci.eclipse.org/releng/job/cocoa_aarch64/configure

* https://ci.eclipse.org/releng/job/cocoa_x86_64/configure

* https://ci.eclipse.org/releng/job/gtk_linux_aarch64/configure

* https://ci.eclipse.org/releng/job/gtk_linux_ppc64le/configure

* https://ci.eclipse.org/releng/job/gtk_linux_x86_64/configure

* https://ci.eclipse.org/releng/job/win32_x86_64/configure

The steps of all those jobs are now perform in the Jenkins-build of this o.e.swt repo and thus makes all the mentioned jobs obsolete. This also makes building the swt-binaries as part of the I-builds obsolete. It has also the advantage that one can get immediate feedback in verification-builds for changes that affect the SWT-binaries.

Since the mentioned seven jobs are now not necessary anymore I suggest we delete them on the long run. For some time I think it is reasonable to keep them as a reference but once we are confident everything works I think we can just delete them.
From how the jobs are configured I assume they are not used for any maintenance work, is that correct.