How to upgrade agents to java 17, but keep java version for builds at java 8, 11, ..?

Using Jenkins
#1

Hi folks, I just read the following instructions:

As far as I understand, this will upgrade the build agents completely to the new java version.

We will skip java 11 and try to upgrade all machines to java 17 directly (master and all slaves), but some of our builds still need older java versions.

So far we had a seperate build agents for each java version. So when a job was running on an agent labeled “java8”, it was expected that any java or javac calls would run with the java 8 versions.

But how would this work now on an agent which has java 17 installed? Are there config params to distinguish between the agent version and the build tools version of java?

All machines are VMs, no docker containers (so far).

#2

Here is a video from @darinpope that describes the configuration of multiple JDK versions:

As a reminder, the term “slave” to refer to an agent has been deprecated since 2016. Please refer to On Jenkins Terminology Updates for more details. We request you update your post.

Thanks,
Mark Waite

1 Like
#3

Short of it is - java used for builds is, in most cases, unrelated to java used for controller/agents. You can use the Tool system to install right versions of JDK as needed. That said, I was under impression that Jenkins did not yet support 17 for running Controller/Agent (you can use it for builds though)

2 Likes
#4

Thanks for the video and the link about the terminology, didn’t know that so far!

#5

I just saw the information here about 11 or 17 being mandatory:

Starting with the weekly release line 2.353, Java 11 or Java 17 will be required to use Jenkins.

And one of our build agents is already running java 17, so I assumed it’s already supported in the current release.

Checking the release notes, I found this, sounds to me like it is supported now?

What’s new in 2.346.1 (2022-06-22)

Allow running on Java 17 without --enable-future-java

We will see, but good point to check that first!

#6

The next lts will require 11 and should support 17. Some say 17 is more stable but not recommended for Lts yet as it’s gotten less testing

If your using weeklies (only two version numbers) then yea 17 should be fine.

After the next lts (very soon now) java 8 support will be dropped and only 11 and 17 will work.

#7

Two more questions arise from this:

Is it possible to bind the JDK to an agent or a label?
Currently each agent has a label like “java8”, “java11”, …
I can set the JAVA_PATH in the agent configuration, but this will be used for the agent, right?
So in our case, should point to the JDK 17?

We are not using pipeline jobs like shown in the video.
Is it still possible to set the tools jdk in a freestyle or maven job?

#8

A label can be assigned to an agent. The label can be used the represent the availability of a specific tool version on that agent. Labels could be java8, java11, and java17 to indicate that those Java versions are available on the agent. Labels could be linux, windows, macOS, FreeBSD, or OpenBSD to indicate the operating system hosting the agent. Labels could be git-1.8 or git-2.36 to indicate the specific version of a tool that is installed on the agent.

If your controller is running Java 17, then your agents should run Java 17. Running Java 17 does not prevent you from installing Java 8 and Java 11 (and other Java versions) on the agent. If they are installed, then jobs can use those other Java installations.