search

jenkins-infra / helpdesk

Open your Infrastructure related issues here for the Jenkins project
https://github.com/jenkins-infra/helpdesk/issues/new/choose
17 stars 10 forks source link

Switch Jenkins Weekly Core Release to drop JDK11 #4135

Closed dduportal closed 5 months ago

dduportal commented 5 months ago

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

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

Reproduction steps

No response

timja commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

basil commented 5 months ago

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 https://github.com/jenkins-infra/jenkins-security-scan/pull/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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

dduportal commented 5 months ago

Update:

dduportal commented 5 months ago

https://github.com/jenkins-infra/release/pull/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 commented 5 months ago

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)