Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JEP-236 Require Java 11 or newer #382

Merged
merged 18 commits into from
Feb 18, 2022

Conversation

MarkEWaite
Copy link
Contributor

@MarkEWaite MarkEWaite commented Jan 28, 2022

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.

Describe the work to allow Jenkins core development to stop supporting
build, test, or execution with Java 8.
@MarkEWaite MarkEWaite requested a review from a team as a code owner January 28, 2022 04:35
Copy link
Member

@timja timja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

few comments

jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
* 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @dduportal might have already done this

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

jep/0000/README.adoc Outdated Show resolved Hide resolved
MarkEWaite and others added 2 commits January 28, 2022 06:12
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
@batmat batmat self-requested a review January 28, 2022 13:42
=== 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a final label, the docker image could include a warning to tell users to switch to another label.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's already an admin monitor to tell them to switch and a pending PR to add an EOL date

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Just not sure how to make it clear to people consuming images that they are out of support.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
Co-authored-by: Jesse Glick <jglick@cloudbees.com>
jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved
* 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which “components” and “tools” are being discussed here? Is this deliberately a sub-bullet of the one discussing plugins?

jep/0000/README.adoc Outdated Show resolved Hide resolved
jep/0000/README.adoc Outdated Show resolved Hide resolved

=== Jenkins Pipeline Library

* `buildPlugin()`, `runATH()`, and `runPCT()` will run tests with JDK 11
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +327 to +328
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean?


* 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

jep/0000/README.adoc Outdated Show resolved Hide resolved
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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@MarkEWaite MarkEWaite changed the title Jenkins core end of Java 8 support Require Java 11 or newer Feb 9, 2022
MarkEWaite and others added 3 commits February 8, 2022 17:30
Co-authored-by: Jesse Glick <jglick@cloudbees.com>
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
@timja timja merged commit 28aa4a7 into jenkinsci:master Feb 18, 2022
@timja timja changed the title Require Java 11 or newer JEP-236 Require Java 11 or newer Feb 18, 2022
@MarkEWaite MarkEWaite deleted the java-8-end-of-support branch February 18, 2022 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants