Auto build the release tool with the dry-run option in post build stage

[sophia-guo]

The current release publish workflow is

1. dry run - manually set the parameter of job https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/
2. rerun the dry run job with dry run parameter unchecked.

The mistakes might happen when manually setting the parameters besides sometime it's hard to find the dry run build if the job is triggered by nightly build automatically at the same time.

If the dry run can be triggered automatically by the pipeline build the process would be easier and more reliable for for release champions.

Part or related with #739

[sophia-guo]

We can do it at two different stages.

• After each jdk build per platform: either in jdk build . Or in pipeline . This way we don't need to wait all platform builds are done.

• After all jdk builds are done, similar to nightly build . Have to wait until all platforms are done.

Either way we need to do per platform so each platform has its own release build job which can be rerun to publish. The build information with url link can be added as pipeline job description e.g https://ci.adoptium.net/job/build-scripts/job/release-openjdk11-pipeline/40/

[sophia-guo]

@smlambert thoughts?

[sophia-guo]

The release job ( not necessarily related with this issue) https://ci.adoptium.net/job/refactor_openjdk_release_tool_new/

[steelhead31]

@sophia-guo I think I like the idea of running a dry run of the release after each platform is built for the nightly build, but I wonder if its possible to have the behaviour different for nightly / release pipelines, and have the dry-run for a release pipeline wait until all jdk builds are done?.

[sxa]

Adjusted the title since I misinterpreted as a proposal to run another complete dry-run pipeline like we do before release after every build :-)

[sxa]

I'm 👍🏻 on this, however some other things to consider:

• The value of this is in having something a job can quickly re-run without the dry-run option. We need to make sure that we can easily find the correct build of the release_tool to be able to publish it. Hopefully we can do that in a way that isn't slower than just re-running it.
• We also need to ensure we are retaining the builds of the release_tool for long enough so they aren't deleted when you want to re-run them. So we'll need ensure they are retained for an absolute minimum of two weeks based on recent release cycles.

[sophia-guo]

The value of this is in having something a job can quickly re-run without the dry-run option. We need to make sure that we can easily find the correct build of the release_tool to be able to publish it. Hopefully we can do that in a way that isn't slower than just re-running it.

I'm thinking attaching all rerun build links to the bottom of the release pipeline job description. When I do the publish I always check the release pipeline job itself. So I think it should be good to attach the rerun links to the release pipeline job itself. If dry run fails the link would be dry run link. If dry run succeeds the link is the publish link.

We also need to ensure we are retaining the builds of the release_tool for long enough so they aren't deleted when you want to re-run them. So we'll need ensure they are retained for an absolute minimum of two weeks based on recent release cycles.

It's common that the rerun links will be mixed or deleted if nightly also triggers the job. Max # of builds to keep need to be increased ( current it's 50). Also might help if nightly and release publish can be separated.

[sophia-guo]

@sophia-guo I think I like the idea of running a dry run of the release after each platform is built for the nightly build, but I wonder if its possible to have the behaviour different for nightly / release pipelines, and have the dry-run for a release pipeline wait until all jdk builds are done?.

I'm not sure if I understand correctly. Currently for nightly build pipelines the binaries are published until all jdk builds are done and no publish process for release build pipeline. Also for nightly there are no dry runs.

Are you suggesting

• nightly pipeline : add dry run process and instead of publishing after all jdks build publishing per platform right after jdk build is done.

• release pipeline: have the dry-run for a release pipeline until all jdk builds are done.

We can definitely have the behaviour different for nightly / release pipelines. Just want to compare the Pros and Cons.

[sophia-guo]

We also need to ensure we are retaining the builds xso they aren't deleted when you want to re-run them. So we'll need ensure they are retained for an absolute minimum of two weeks based on recent release cycles.

Actually if we don't care about of the dry run build we might not need to keep that build.

We can provide the dry run build in two ways. One is the link of dry run build itself, which asks to retain the builds of the release_tool for long enough so they aren't deleted when you want to re-run them. The dryrun link would be 'https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/dryrunbuildNumber/'

The other way is just to provide the rerun link of the dry run (same parameters of the dry run) something like 'https://ci.adoptium.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/parambuild/?TAG='specificTag'&&VERSION='specificVersion'&RELEASE=true&UPSTREAM_JOB_NAME='upsteamjobname'&UPSTREAM_JOB_NUMBER='jobnumber'&ARTIFACTS_TO_COPY='specifiedFilter'&ARTIFACTS_TO_SKIP="**/*testimage*'"&DRYRUN=false'. This way no dry run build itself is required to keep.

[sophia-guo]

option 1 - running a dry run of the release after each platform is built
https://github.com/adoptium/ci-jenkins-pipelines/compare/master...sophia-guo:release1?expand=1

option 2 - running the dry-run for a release pipeline wait until all jdk builds are done
https://github.com/adoptium/ci-jenkins-pipelines/pull/916/files

[sxa]

option 1 means you have each platform as an individual dry-run job which is consistent with what we need during a release cycle since we don't publish all together. There are two sub-options within this though
1a) Start the dry run within the individual platform pipelines, but that would require it to pull from the platform pipelines, which is now where we usually publish from
1b) Start the dry run from the openjdkXX-pipeline after the platform pipeline is complete (maybe just after the artifacts are archived from the subjob).

1b is probably better as it can point to the release-openjdkXX-pipeline for the artifacts, and also keeps all of the references to the dry-run jobs in one place making them easier to find.

I'm thinking attaching all rerun build links to the bottom of the release pipeline job description.

Yes I agree - that would be really useful I think.

[sophia-guo]

@sxa https://github.com/adoptium/ci-jenkins-pipelines/compare/master...sophia-guo:release1?expand=1 is option1 with sub option 1b.