Nearly done with our Jenkins JDK17 upgrade!
This migration required
• sequencing by component, risk
• changes made by partner teams
• progress reporting
• minimizing user impact
Many teams face the same challenges so I’m putting together a post about it. If you have questions the post could answer, or would be interested in reading a draft, please get in touch.
@sghill You should encourage downstream teams to use DSL like JDK DSL https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.jobs.MavenJob.jdk .
The build agent Java instance is only needed for establishing a connection with the controller, Maven and JDK, etc.. DSL means the job can ask the controller for the appropriate installer and will then use that JDK for building.
If you combine this with the Config Provider DSL https://plugins.jenkins.io/config-file-provider/ you have a means to define the entire build environment through IaC.
@stevecrox nice approach!
We have something similar for projects created in the past few years. The required JDK version is stored alongside the code, and is simple to upgrade.
Legacy projects are where it gets tricky for us. We can’t block our migration on every project defining a JDK, so we’ve moved the agent connection JDK to 17 while leaving PATH and JAVA_HOME set to JDK 8.
Behold: https://plugins.jenkins.io/remote-file/ this allows you to define Jenkinsfiles within a remote repository and check them out into the build job assuming a marker exists (e.g. pom.xml, package.json, etc..).
That lets you create a centrally managed Jenkinsfile, using the approach I outlined before. That gives you an easy path to migrate the Old projects to a standard DSL approach.
Unless they have been truely unique it lets you push everything on to a modern approach.
sghill
stevecrox