Update x64 Mac build jobs to use macos11 label

[Haroon-Khel]

In light of adoptium/infrastructure#2536 (comment) and adoptium/temurin-build#3354, and now that adoptium/temurin-build#3492 is in we can force the builds to run on Macos11 machines only.

I am positive I have updated the correct files, but feel free to correct me if I have not.

There is one problem. This line,

ci-jenkins-pipelines/pipelines/build/common/config_regeneration.groovy

Line 465 in 5fcae13

NODE_LABEL: "${additionalNodeLabels}&&${platformConfig.os}&&${archLabel}",

, will insist that the NODE_LABEL contains the architecture of the binary to build, in this case x64. So the final label will be "NODE_LABEL": "macos11&&build&&mac&&x64" which will prevent it from running on our arm mac build machines.

An easy solution is to add x64 labels to our build arm mac machines. A harder solution is to modify

ci-jenkins-pipelines/pipelines/build/common/config_regeneration.groovy

Line 465 in 5fcae13

NODE_LABEL: "${additionalNodeLabels}&&${platformConfig.os}&&${archLabel}",

to something more versatile which will not break the other build jobs, but at the moment I do not know this repo well enough for this to be a quick fix before the next release.

@sxa @andrew-m-leonard thoughts?

An easy solution is to add x64 labels to our build arm mac machines.

I'm in favour of this

[github-actions]

Thank you for creating a pull request!

Please check out the information below if you have not made a pull request here before (or if you need a reminder how things work).

Code Quality and Contributing Guidelines

If you have not done so already, please familiarise yourself with our Contributing Guidelines and Code Of Conduct, even if you have contributed before.

Tests

Github actions will run a set of jobs against your PR that will lint and unit test your changes. Keep an eye out for the results from these on the latest commit you submitted. For more information, please see our testing documentation.

In order to run the advanced pipeline tests (executing a set of mock pipelines), it requires an admin to post run tests on this PR.
If you are not an admin, please ask for one's attention in #infrastructure on Slack or ping one here.
To run full set of tests, use "run tests"; a subset of tests on specific jdk version, use "run tests quick 11,21"

[sxa]

I don't think this will work - it'll look for macos11&&build&&mac&&x64 (which we don't have any of) instead of selecting an aarch64 build machine

[sxa]

Take a look at the crossCompile sections in jdk11u for 32-bit arm and riscv64 for an example of how to make it run on a different machine. Hopefully something that that will work here too.

[Haroon-Khel]

Take a look at the crossCompile sections in jdk11u for 32-bit arm and riscv64 for an example of how to make it run on a different machine. Hopefully something that that will work here too.

I have added x64 labels to the build-arm-mac machines so they now show up in https://ci.adoptium.net/label/macos11&&build&&mac&&x64/. Let's merge this pr and if we see stable builds then I can implement a more versatile solution

@sxa @andrew-m-leonard

[sxa]

While it's not ideal having that label on a machine that is of a different architecture I'll approve this on the basis that this is an interim solution for next week's release and we will look at doing it properly for the next release. Let's also make sure that when we merge this we take the build label OFF the x64 ones (and log here which machines that's been done on) to ensure that we don't end up with a random selection of x64 or aarch64 systems used for builds which could affect reproducibility

[andrew-m-leonard]

I think we might be able to use the crossCompile option, eg:

ci-jenkins-pipelines/pipelines/jobs/configurations/jdk21u_pipeline_config.groovy

Line 179 in 633cb3d

crossCompile : 'x64',

?

[Haroon-Khel]

@andrew-m-leonard Right now ive labelled our build-arm-mac machines with x64 so this will allow the arm mac build jobs to run on the appropriate machines. This is only a temp solution to see if we get a stable run of nightlies, and then I can implement a more long term solution using

ci-jenkins-pipelines/pipelines/jobs/configurations/jdk21u_pipeline_config.groovy

Line 179 in 633cb3d

crossCompile : 'x64',

(in a separate pr after the release)

You should know that with this pr merged only build-macstadium-macos11-arm64-1 and build-macstadium-macos11-arm64-2 will be used for building arm and x64 mac for the major jdk versions. I believe testing will still be done on both the x64 and arm64 test machines

[Haroon-Khel]

I just remembered, for cross compiling jdk11+ the --openjdk-target=x86_64-apple-darwin needs to be added to the configure args, so we cant merge this until changes are added for this

[github-actions]

A block has been put on this Pull Request as this repository is temporarily under a code freeze due to an ongoing release cycle.

If this pull request needs to be merged during the release cycle then please comment /merge and a PMC member will be able to remove the block.

If the code freeze is over you can remove this block by commenting /thaw.

[sxa]

I just remembered, for cross compiling jdk11+ the --openjdk-target=x86_64-apple-darwin needs to be added to the configure args,

Oh https://github.com/adoptium/temurin-build/pull/3492/files was only doing the change for JDK8 - ok in that case I guess we'll need another temurin-build PR for 11+.

we can merge this until changes are added for this

Should that be "can't"?

[Haroon-Khel]

Should that be "can't"?

Havent had my coffee this morning 😅

Oh https://github.com/adoptium/temurin-build/pull/3492/files was only doing the change for JDK8 - ok in that case I guess we'll bee need another temurin-build PR for 11+.

On it

[Haroon-Khel]

adoptium/temurin-build#3502 is ready to review

[Haroon-Khel]

/merge

[github-actions]

Approval to merge during the lockdown cycle

Please can two Adoptium PMC members comment /approve?

[sxa]

/approve

[andrew-m-leonard]

/approve

Thank you @sxa and @andrew-m-leonard for your approvals, this pull request is now approved to merge during release.