Skip to content

Setting up new build jobs, mirrors,... when a new openjdk version is branched from jdk(head)

Jump to bottom
Andrew Leonard edited this page Dec 11, 2024 · 38 revisions

When and why?

Scenario 1 (non-u repository)

When a new jdk release is created upstream eg.jdk-23, a new upstream branch is branched from jdk(head) master, so https://github.com/openjdk/jdk branch jdk23. We then mirror this new branch in the jdk(head) mirror repository, https://github.com/adoptium/jdk.

Scenario 2 (u repository)

Once shipped upstream moves to development of updates for the following .0.N updates, this is done in a new repro https://github.com/openjdk/jdk19u, known as the "updates" repo. We need to create a new mirror for this "updates" repo after the initial release has been shipped.

Prerequistes:

Update the jdk(head) adoptium mirror to mirror the new jdkNN version branch - Scenario 1 (non-u repository)

  1. Edit the existing adoptium mirror Jenkins job configuration "shell script": https://ci.adoptium.net/view/git-mirrors/job/git-mirrors/job/adoptium/job/git-skara-jdk/configure, "Build Steps" - "Execute shell" content. Update the "branches" variable to have the new jdkNN version branch to be mirrored:
branches="master jdk23 jdkNN"
  1. Save, and run the update job to mirror the new jdkNN version branch.

Create the new adoptium mirror - Scenario 2 (u repository)

  1. Create the new mirror jdkNNu repository using otterdog: https://github.com/adoptium/.eclipsefdn Create a new PR for file https://github.com/adoptium/.eclipsefdn/blob/main/otterdog/adoptium.jsonnet and add a definition like this is we're add a u repository:
 newMirrorRepo('jdkNNu') {},

Also note that that after the mirror is created it can take up to three hours for the permissions to start working if you need to do it manually.

Steps 2-5 are no longer required to be run manually and the first run of the skara mirror jobs will populate the repository
  1. Once the new repository has been created, populate it with a mirror of the existing adoptium one (u release):
git clone --mirror [email protected]:openjdk/jdkNN[u].git
cd jdkNN[u].git
git push --mirror [email protected]:adoptium/jdkNN[u].git

Ignore any errors attempting to push to branch "main". Verify repository populated successfully with branch "master".

  1. Delete any upstream "pr/nn" branches (There typically shouldn't be any for a new u release as we will have removed them in the non-u mirror_.

  2. Create the "dev" branch with necessary patches:

git checkout -b dev origin/master

Apply "Adoptium" patches, "Files changed" => https://github.com/adoptium/jdk/compare/master...dev

Commit changes and push:

git push origin dev
  1. Create the "release" branch with necessary patches:
git checkout -b release origin/master

Apply "Adoptium" patches, "Files changed" => https://github.com/adoptium/jdk/compare/master...release. This should include, as a minimum, the mandatory README.JAVASE file.

Commit changes and push:

git push origin release
  1. Create the skara mirror job:
bash ./skaraMirror.sh jdkNN[u]

This can also be done manually by running the script after cloning https://github.com/adoptium/mirror-scripts

  1. Build the new git-skara-jdkNN[u] job. It should now mirror any new upstream openjdk commits to master, merge with dev, and create the release branch. Verify the job completes successfully and the repository content looks correct. The first time you run it you may get a message fatal: no such branch/commit 'master' - this should go away on the next run .

  2. If "main" branch was auto-created as "default" branch: Raise an Eclipse Help Desk issue to change the "default" branch to "master", and to delete the "main" branch.

For a non-u release, ensure the temurinNN-binaries repository is created

  1. Does https://github.com/adoptium/temurinNN-binaries exist (You may have created one in the same PR when you created the source code mirror)
  2. If not create using "otterdog": https://github.com/adoptium/.eclipsefdn Create a new PR for file https://github.com/adoptium/.eclipsefdn/blob/main/otterdog/adoptium.jsonnet and add a definition like:
  newBinaryRepo('temurin24-binaries') {},

Update TRSS configuration to add the new version build pipelines

  1. Contact the TRSS owner (Shelley Lambert), to update the TRSS configuration to add the following new build pipelines:
  • openjdkNN-pipeline
  • release-openjdkNN-pipeline

If jdk(head) has branched to next jdk version (a non-u release) generate new jdk(head) build jobs

  1. Create the new jdkNN head pipeline config, eg:https://github.com/adoptium/ci-jenkins-pipelines/pull/859/files
  • Create jdkNN.groovy
  • Create jdkNN_evaluation.groovy
  • Create jdkNN_release.groovy
  • Create jdkNN_pipeline_config.groovy
  • Create PR and merge
  1. Update JAVA_VERSION in build job generator https://ci.adoptium.net/job/build-scripts/job/utils/job/pipeline_jobs_generator_jdk/ to the new jdk version
  2. Run the updated pipeline_jobs_generator_jdk
  3. Run the build-pipeline-generator to generate the openjdkNN-pipeline
  4. Repeat for the evaluation_pipeline_jobs_generator as well:
  • Update JAVA_VERSION in evaluation-pipeline_jobs_generator_jdk to new jdk version
  • Run the updated evaluation-pipeline_jobs_generator_jdk
  1. For the previous jdkNN head version create the pipeline(& evaluation-)_jobs_generator_jdk(NN-1)
  • Create a new job based on the "pipeline_jobs_generator_jdk" called "pipeline_jobs_generator_jdk(NN-1)", and change the JAVA_VERSION to "jdk(NN-1)"
  • Create a new job based on the "evaluation-pipeline_jobs_generator_jdk" called "evaluation-pipeline_jobs_generator_jdk(NN-1)", and change the JAVA_VERSION to "jdk(NN-1)"

Create pipeline_jobs_generator_jdkNN[u] job and configuration

  1. For u version, jdkNN->jdkNNu, create the jdkNNu pipeline job configuration: https://github.com/adoptium/ci-jenkins-pipelines/tree/master/pipelines/jobs/configurations, using the previous jdkNN version file contents as a basis:
  • Rename jdkNN.groovy to jdkNNu.groovy
  • Rename jdkNN_evaluation.groovy to jdkNNu_evaluation.groovy
  • Rename jdkNN_release.groovy to jdkNNu_release.groovy
  • Rename jdkNN_pipeline_config.groovy to jdkNNu_pipeline_config.groovy
  • Create PR and merge
  1. For u version, jdkNN->jdkNNu, rename existing job: eg.https://ci.adoptopenjdk.net/job/build-scripts/job/utils/job/pipeline_jobs_generator_jdkNN to pipeline_jobs_generator_jdkNNu
  2. For new branch head version, copy an existing generator, eg.pipeline_jobs_generator_jdk(NN-1)u, and create as pipeline_jobs_generator_jdkNN
  3. Change JAVA_VERSION parameter to "jdkNN[u]"
  4. Build the pipeline_jobs_generator_jdkNN[u] job, and ensure the new pipeline build jobs are created: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/
  5. Repeat for the evaluation_ and release_ pipeline_jobs_generators as well.

Run a test pipeline build

  1. Build the newly generate pipeline job : https://ci.adoptopenjdk.net/job/build-scripts/job/openjdkNN-pipeline/
  2. Verify all build successfully

Update refactor_openjdk_release_tool to support jdk new head version

  1. Go to Configure for job https://ci.adoptopenjdk.net/job/build-scripts/job/release/job/refactor_openjdk_release_tool/ and add the new jdk head to the VERSION choices parameter

Update daily Slack status job with new jdkNN status

  1. Go to Configure for job https://ci.adoptium.net/view/Tooling/job/nightlyBuildAndTestStats_temurin/configure
  2. For Add or Update to u "jdkNN[u]" in FEATURE_RELEASES
  3. Update TIP_RELEASES with new "head" jdkNN versions

Create or update release trigger jobs

If we have created a mirror for a new major release, it will need a release trigger job to be able to detect and build new tags, which we build and ship early access builds from.

The jobs which run these builds are in the utils folder on jenkins and are named releaseTrigger_XXea.

  • If you are transitioning from a non-u (jdk(head) version branch) to a u updates repository, then you can simply update the MIRROR_REPO reference in the job from the jdk(head) repository to the new jdkNNu updates mirror repository. Do NOT add the u to the JAVA_VERSION parameter. The binaries repository will be unchanged as it never has the u suffix in the name.
  • If you are creating a new major non-u version, then you should create a copy of the old releaseTrigger jobs with the new version number, and then update all references to the old version to the new one, including the temurin-binariesNN repository.
Clone this wiki locally