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).
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.
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)
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?
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.
But we have over 300 jobs now and “then jobs can use those other Java installations” means I would have to modify all 300 jobs to do exactly that. Currently they all have the label set to the Java version they need, e.g. “java8”.
I have looked at the node configurations we have and I saw something interesting:
One of the agents has this set:
Under “Launch method” → “Advanced” → “JavaPath” it has:
/opt/jdk8/bin/java
This java Path will be used to start the jvm. (/mycustomjdkpath/bin/java ) If empty Jenkins will search java command in the agent
Expressions such as key or {key} may be declared in the java Path and will be expanded to values of matching keys declared in the list of environment variables of this node, or if not present, in the list of global environment variables.
(from SSH Build Agents plugin)
Environment variables defined here will be made available to every build executed by this agent, and will override any environment variables that have the same Name as those defined on the Configure System page.
Using the syntax $NAME or ${NAME} (%NAME% on Windows), these variables can be used in job configurations, or from process launched by a build.
Does this mean if I set the JavaPath to the Java 17 installation, I can use the JAVA_HOME for the Java 8/11/14 installation? Or am I missing something important here?
I’m just trying to avoid to modify so many jobs all containing different technologies for the build.
Or even worse, to tell people to convert every job to a pipeline jobs just to configure the jdk.
As far as I can tell from your descriptions, your job definitions are tightly coupled to the Java version that is running the agent. The Jenkins documentation states that agents should be run with the same Java version that runs the controller. You can’t have jobs that are tightly coupled to the Java version (in your case Java 8 and Java 11), run the controller on Java 17, and also comply with the requirement that agents must run the same Java version as the controller.
I believe that your options are:
Redefine the jobs so that they are not tightly coupled to the Java version running the agent
Remain with Java 8 on the controller and the agents, accepting that you’re locking yourself into a Java version that the Jenkins project is dropping from support
To add to that, the easiest way to go is to use java “tools” definitions, - Jenkins tool system can happily install the right version of Java on the agent you are running when it is missing, instead of creating a dedicated agent for every java version and the jumping versions.
my master jenkins debian 10 and java 11 ,
my agents debian 11 and java 11 of same version of master but agents build dynamically by instance templets…
my problem is some builds supports only java 8 , will java 8 can install automatically during build ? because debain 11 supports java version11 and above…
please suggest solution for this issue…
