Switch Jenkins Weekly Core Release to drop JDK11

[dduportal]

Service(s)

release.ci.jenkins.io

Summary

As per https://www.jenkins.io/blog/2024/06/11/require-java-17/, the upcoming Jenkins weekly release will require JDK17 at least to run.

As such, we have to drop JDK11 used to build it in the release process and use another LTS line: at least JDK17 and eventually JDK21.

Note: ci.jenkins.io builds of Jenkins Core are already running with JDK17 and JDK21 on Linux: https://github.com/jenkinsci/jenkins/blob/master/Jenkinsfile

• The release pipeline is defined in https://github.com/jenkins-infra/release/blob/master/Jenkinsfile.d/core/release
• The JDK version is provided by the agent image, defined by a PodTemplate in https://github.com/jenkins-infra/release/blob/master/PodTemplates.d/release-linux.yaml
• The agent template utilizes the jenkinsciinfra/packaging image in a 4.x version
• This image is defined in https://github.com/jenkins-infra/docker-packaging/blob/main/Dockerfile with:
  • JDK17 used for the agent runtime (same as release.ci.jio's controller) from the parent jenkins/inbound-agent image
  • JDK11 retrieved from a Temurin image (see https://github.com/jenkins-infra/docker-packaging/blob/3fb7d59e10019e895cce1173e352f7600a91ac79/Dockerfile#L99)

=> Proposal is to define the new JDK17 or JDK21 in the same way as today and generate a 5.x image:

• Keeping the parent's image JDK allows Jenkins Infra. Admins to switch the agent runtime to 21 soon without breaking the image (ref. Move agents to JDK21 (runtime) #4121)
• Breaking change because JDK major upgrade, hence the 5.x version scheme (need careful PR message for the automatic semantic versioning!)
• All LTS lines between today and end of October (when JDK11 is dropped finally from Jenkins Core) will be with a version <= 2.462. Since the jenkins-infra/release repository uses distinct branches, these LTS will keep the 4.x line while weekly will use the 5.x image
• ⚠️ we need to work on Streamline Maven versions across the infrastructure #4110 in the 4.x line before to have modern Maven

Reproduction steps

No response

[timja]

Could we just move to 21? I'm not sure why there's a point in the infra having a stepping stone to 17.

As far as I understand 17 was only kept for CloudBees customers rather than skipping straight to 21.

[dduportal]

Could we just move to 21? I'm not sure why there's a point in the infra having a stepping stone to 17.

As far as I understand 17 was only kept for CloudBees customers rather than skipping straight to 21.

I asked because I remember discussions with @jtnord @daniel-beck @jglick @basil and other maintainer around the bytecode of the Core release being subtly different between major JDKs used. Devil being in details, it might, or might not have impact.

I agree with your point: maintenance wide, jumping to JDK21 directly makes more sense to have more time in front of us: I vote for JDK21 with the "admin maintenance" hat.

[timja]

(fixed @jtnord's handle, separate message as I don't think edits trigger notifications)

[basil]

We already run tests with both Java 17 and 21 across the board, in core and plugin Jenkinsfiles. As far as releases go, James has correctly identified that the Java 17 bytecode produced by the Java 21 compiler (with -release 17) and the Java 17 compiler may be different at times. While there is the potential for regression here, I have never seen this in practice and it seems rare. So I have no strong preference which compiler we choose. The maven-cd workflow defaults to 17 in https://github.com/jenkins-infra/github-reusable-workflows/blob/9f24d85a47bc126feb2afa05ee3bb40872139c8f/.github/workflows/maven-cd.yml#L55 and something similar is being proposed in jenkins-infra/jenkins-security-scan#30 so I would prefer we be consistent with core releases by using Java 17. But if someone wanted to update all three of the above to Java 21, I wouldn't be opposed to that, I think the risk would be low, and the reward might be high in that it would save us from having to think about this again for another few years.

[jtnord]

Mostly the issues I have seen around the bytecode cause false positives in spotbugs.

I'm not too worried now we do not perform bytecode manipulation in Jenkins (although I may be incorrect and may have seen bridge methods lately), developers already often test a locally built war using a different JVM and sometimes a completely different (non javac) compiler).

The main thing would be to know what version was used such that reproducible builds can be achieved, but that is a different issue not impacted by the change to any particular JVM.

My general preference is to always use the JVM that you are targeting, but it is a preference and what the project chooses to do is fine with me so long as it is deterministic (which it is)

[basil]

The bridge method injector is definitely still in use, but its changes are much less invasive post-JENKINS-67011—certainly nothing that I think is relevant to this issue one way or another.

[dduportal]

Update: we decided to go with JDK17 for now following these arguments:

• Homogeneity with CD process
• Running the procedure again for 17 -> 21 will be sane for the infra (for a low cost)
• Keeping bytecode generated with the same version as minimal

[dduportal]

Update:

• PR by @jayfranco999 to track JDK version (and use 17 major version): chore(updatecli) Track JDK version docker-packaging#115
• Automated PR bumping build JDK to JDK17: Bump JDK17 version to 17.0.11_9 docker-packaging#118
• Released version: https://github.com/jenkins-infra/docker-packaging/releases/tag/5.0.0

[dduportal]

jenkins-infra/release#550 => JDK17 is ready to be used for the build. I'm keeping the issue open until tomorrow's weekly release (2.463) is built and ready

[dduportal]

The release 2.463 was successfull: https://get.jenkins.io/windows/2.463/jenkins.msi?mirrorlist. We can close this issue.

Note: the JDK21 upgrade will be easy when the time will come: changing https://github.com/jenkins-infra/docker-packaging/blob/c7f7c264ed40d3f4639bad072fa5e3b2ea1edaf6/updatecli/values.yaml#L12 (or using the new all-in-one image)