I need to upgrade our Jenkins-Docker-Container from version 2.153 to 2.335.
At the moment our java-pipelines are using Java-8 and we wanna upgrade our java-pipelines to Java-11, thats the reason why I want to upgrade the whole jenkins (“2.335-jdk11” docker-tag).
But with the new Jenkins (2.335-jdk11), I also want to have Java-8 installed.
I know there is the possibility to have multiple JDK in Jenkins:
Do you’ve any tips/hints for the Jenkins-Docker-Container-Upgrade from 2.153 to 2.335?
There will be no lost of existing pipelines, it’s fully compatible?
If I’m installing the Java-8 and reboot the container, I think Java-8 is then gone/away (because it’s not installed in a docker-volume)? How can I install Java-8 in the new Jenkins-Docker-Container to have it reboot-persistent?
That’s proposing an upgrade from a weekly that was released over 3 years ago to the most recent weekly. Since your upgrade pattern seems to be infrequent, you should consider a switch from weekly release line to the long term support release line as part of this upgrade. Current long term support release is 2.319.3.
In order to make the upgrade in smaller steps, you could upgrade to 2.319.3 running Java 8. The Java 8 container image is jenkins/jenkins:2.319.3-jdk8. Ultimately, you will switch to jenkins/jenkins:2.319.3 for Java 11, but you can make the transition from Java 8 to Java 11 as a step that is separate from the transition from 2.153 to 2.319.3.
Don’t install Java 8 in the container used for the Jenkins controller. Run your jobs on an agent and have Java 8 (or other tools) installed on that agent instead of installing them on the controller.
The Jenkins documentation explains the details why that is the preferred approach.
There are also videos that describe the purposes of Jenkins agents, like
Create a new container that is based on the jenkins/jenkins:2.319.3 container image but includes the plugins you use, managed as code with a plugins.txt file. You can use that container image to experiment with the upgrade without breaking your existing installation.
If you’re interested to see how others have done it, there are public repositories available that illustrate it. My lts-with-plugins branch is one example. There are others, I’m sure.
There were major Jenkins upgrades across the time that you’re considering. Your most reliable path would be to review the LTS upgrade guides for each of the LTS versions between 2.153 and your destination version. Some of the most common areas of difficulty include the configuration form modernization that was released in 2.277.1 LTS and is described in this blog post
The detailed steps for the configuration form modernization upgrade are also described in
Okay, so that means for the first upgrade step I will use the official docker-tag “jenkins/jenkins:2.319.3-lts”. And then for the second upgrade step I will use the official docker-tag “jenkins/jenkins:2.319.3-lts-jdk11”.
Is it right? But why I need to do the JDK-11 Upgrade separatly, you did not explained the reason, what is the benefit of it? It is possible directly go to “jenkins/jenkins:2.319.3-lts-jdk11”?
Regarding the Jenkins-Agent, this is overheaded for us, because we need this JDK-8 only temporary until all our Jenkins-Pipeline are able to use JDK-11. In time we speak about one month or so, after that everything should running on JDK-11 and we don’t need JDK-8 anymore.
The following procedure is still possible with the “jenkins/jenkins:2.319.3-lts-jdk11”, right?
Almost. If you want to stay on JDK 8 in order to reduce the size of each step of the upgrade, then you would use jenkins/jenkins:2.319.3-jdk8 as the Docker container for the first step. After that first step of the upgrade is complete, you would upgrade to Java 11 by using the jenkins/jenkins:2.319.3 container or its more precisely labeled alias jenkins/jenkins:2.319.3-jdk11.
Yes, if you don’t mind making a larger upgrade step, then you can go directly to JDK 11.
Even if you don’t need JDK 8 any longer, you should prefer to have no executors on the controller and configure agents to execute the jobs. See the article on controller isolation for the list of reasons
Yes, Jenkins allows builds to run with many different JDK versions. We use Java 8, Java 11, and Java 17 regularly on ci.jenkins.io with the controller running Java 11. There are many users that run multiple JDK versions with Jenkins jobs. It works very well.
This video includes an example that configures an Apache Maven tool to use a different JDK
