JEP-236 Require Java 11 or newer #382
Conversation
Describe the work to allow Jenkins core development to stop supporting build, test, or execution with Java 8.
| * ATH is performed successfully on Java 11 | ||
| * PCT is updated as needed to run on Java 11 | ||
| * PCT is performed successfully on Java 11 | ||
| * Packaging tests are performed successfully on Java 11 |
There was a problem hiding this comment.
I think @dduportal might have already done this
There was a problem hiding this comment.
Not yet (ref. jenkins-infra/release#199) but JDK11 is available on the current release process so easy to switch.
We can plan to do it for the 1st time for the weekly of the 7th of feb.(or later).
Co-authored-by: Tim Jacomb <[email protected]>
| === Jenkins Docker packaging | ||
|
|
||
| The containers tagged for Java 8, like `latest-jdk8` and `centos7-jdk8` will no longer be updated. | ||
| The upgrade guide and the announcement blogpost will note that users must switch to other images. |
There was a problem hiding this comment.
As a final label, the docker image could include a warning to tell users to switch to another label.
There was a problem hiding this comment.
Good suggestion. I'm not sure how that would best be implemented.
Would the Docker image add a new "flag file" to Jenkins home directory (this image is no longer being updated) and then the presence of that flag file would cause an administrative monitor to be displayed?
Is there a better way to get the message to the Jenkins administrator that they are using a Docker image that is no longer receiving updates?
There was a problem hiding this comment.
I just thought about a plain warning message in stderr, but indeed, that could go further and be implemented as an administrative monitor as you suggest.
There was a problem hiding this comment.
there's already an admin monitor to tell them to switch and a pending PR to add an EOL date
There was a problem hiding this comment.
I just thought about a plain warning message in stderr, but indeed, that could go further and be implemented as an administrative monitor as you suggest.
I fear that warnings to the stderr of a Jenkins controller will not be seen by most administrators.
There was a problem hiding this comment.
there's already an admin monitor to tell them to switch and a pending PR to add an EOL date
I was thinking that this admin monitor would be informing the user that the Docker image is no longer being updated. We could have used that for the end of life of the centos8 image and would need something similar for the end of life for the Debian 10 (buster) image when Debian 12 is released.
I guess that an admin monitor may not be well suited for that idea, since we would want a distinct admin monitor for each image end of life. If we tried to use the same admin monitor for all image end of life messages, then the administrator may have dismissed the end of life for an earlier image and we need to show them that the current image they are using has reached the end of its life
There was a problem hiding this comment.
Once we start shipping security advisories solely on post-8 versions, I do not think we can leave Docker images based on 8 as is in good conscience. At that point I think we need to take down the original images.
There was a problem hiding this comment.
Once we start shipping security advisories solely on post-8 versions, I do not think we can leave Docker images based on 8 as is in good conscience. At that point I think we need to take down the original images.
That would be different than our current practice and different than many other providers of Docker images. For example:
- Ubuntu images on hub.docker.com still list older tags, even if there are known vulnerabilities
- Alpine images on hub.docker.com still list older tags, even if there are known vulnerabilities
We've followed a similar practice to Ubuntu and Alpine when we stopped updating the CentOS 8 Docker image in August. We delivered 2.306-centos as the last version with centos8 and did not remove that label when the security advisories were posted that affected that version
There was a problem hiding this comment.
OK. Just not sure how to make it clear to people consuming images that they are out of support.
There was a problem hiding this comment.
OK. Just not sure how to make it clear to people consuming images that they are out of support
I think you're right that we have a problem there. We don't have a way to tell users that the Docker image they are using is no longer being updated. Maybe we should consider a new administrative monitor each time we stop updates on a Docker container. If Jenkins is running in a container that is no longer being updated, we tell the administrator at least once that they need to move to a different Docker label.
| ==== Issue tracking | ||
|
|
||
| * Issues related to Java 8 end of support are tracked as Jenkins issues | ||
| ** link:https://issues.jenkins.io/browse/JENKINS-67688[JENKINS-67688] is the Jira epic that tracks issues in Jira |
There was a problem hiding this comment.
Not helpful yet since it is empty.
IMHO the scope of changes & rollout plan should reflect the work of going through https://issues.jenkins.io/issues/?jql=resolution%20%3D%20Unresolved%20and%20labels%20in%20(java11%2C%20java11-compatibility%2C%20java11-devtools-compatibility) and https://issues.jenkins.io/browse/JENKINS-40689 to look for serious unresolved problems. For example, https://issues.jenkins.io/browse/JENKINS-59910 seems to be a blocker.
There was a problem hiding this comment.
I've started the review of issues in those lists and have assigned a few of them to the epic. As I'm able to complete more reviews or as others are able to complete reviews, more items will be added.
Co-authored-by: Jesse Glick <[email protected]>
| * Jenkins replace older API calls with Java 11 API calls | ||
| ** Jakarta EE upgrade is not required as part of this JEP | ||
| * All plugins are operational with Java 11 | ||
| ** Some Jenkins components may be updated to support features offered in Java 11 and beyond, but there is no plan to update all tools |
There was a problem hiding this comment.
Which “components” and “tools” are being discussed here? Is this deliberately a sub-bullet of the one discussing plugins?
|
|
||
| === Jenkins Pipeline Library | ||
|
|
||
| * `buildPlugin()`, `runATH()`, and `runPCT()` will run tests with JDK 11 |
There was a problem hiding this comment.
And buildPlugin will compile using JDK 11, even if the plugin is still compatible with 8. -release should ensure that the plugin does not accidentally use post-8 APIs. It might however begin implicitly relying on behavioral changes between 8 and 11, resulting in a functional incompatibility with older core versions running on 8.
| Ending Java 8 support in Jenkins requires significant testing. | ||
| Community contributors will be encouraged to test environments and configurations to assure that Jenkins core no longer requires Java 8. |
There was a problem hiding this comment.
Again I think this is better expressed in terms of requiring 11 and ensuring that everything runs smoothly on 11.
| * PCT is updated and successful on Java 11 | ||
| * Plugin bill of materials is updated and successful on Java 11 | ||
| * Packaging tests are performed successfully on Java 11 | ||
| * Exploratory tests are performed successfully to check for inadvertent use of Java 8 |
|
|
||
| * ATH is updated and successful on Java 11 (**done** in link:https://github.com/jenkinsci/acceptance-test-harness/pull/726[ATH PR 726]) | ||
| * PCT is updated and successful on Java 11 | ||
| * Plugin bill of materials is updated and successful on Java 11 |
There was a problem hiding this comment.
Unclear what this means. Do you mean that the bom PCT tests pass on 11? If so, then this is the same as the previous bullet point, since AFAIK nothing else in Jenkins infra actually runs PCT.
The Oracle support lifecycle is not the compelling reason for this change. Remove it from the abstract.
|
|
||
| ==== Jenkins Agent Images | ||
|
|
||
| Java 8 images will no longer be provided for the general purpose agent containers: |
There was a problem hiding this comment.
What's going to be the policy for compatibility with agents? Would a controller running on Java 11 work with an agent running on Java 8? IOW once Java 11 APIs can be used in Jenkins core, are they going to be allowed in classes that are known to be serialized to agents?
There was a problem hiding this comment.
Would a controller running on Java 11 work with an agent running on Java 8?
No, the agent would need to be running 11 (or later) as well.
once Java 11 APIs can be used in Jenkins core, are they going to be allowed in classes that are known to be serialized to agents?
Yes.
Better title to make it clear what is changing
MarkEWaite
changed the title
Co-authored-by: Jesse Glick <[email protected]> Co-authored-by: Tim Jacomb <[email protected]>
More details Also added issues to epic https://issues.jenkins.io/browse/JENKINS-67688
Require Java 11 or newer
Describe the work to allow Jenkins core development to require Java 11 or newer. Stop supporting build, test, or execution with Java 8.