Plugin-Pinned LTS Upgrade on a Full Controller
Your team runs Jenkins 2.361.4 on a single Ubuntu 20.04 VM. JENKINS_HOME sits on a 200 GB volume that is 91% full, the controller has 4 GB RAM and 12 executors, and it also runs builds. You have 420 jobs (90 Pipeline), 25 permanent agents, and 38 plugins; six plugins are pinned because a vendor supports only those versions. Management wants the current LTS within two weeks and then Java 17, but the vendor plugin is certified only on Java 11. On a cloned test instance, the upgrade reached the setup wizard and then failed with a plugin dependency error; two freestyle jobs also failed with 'No such DSL method' after the clone. The controller log shows repeated garbage-collection pauses. You must produce a migration plan that keeps the vendor integration working, recovers disk headroom, and gives a tested rollback.
1. Sequence the upgrade from 2.361.4 to the target LTS, including the Java 11 versus Java 17 decision. What do you do first, and what is the fallback if the vendor plugin blocks Java 17?
Read the worked answer
Start with a recoverable copy, not with the production controller. Stop Jenkins, snapshot the VM, and tar JENKINS_HOME including jobs/, plugins/, config.xml, credentials.xml, secrets/, and the service unit/JVM options. On the clone, upgrade directly to the target LTS while still on Java 11 if that LTS supports it; 2.452.x does, so the vendor plugin is not immediately a blocker. Upgrade plugins only after the core, using the update center or jenkins-plugin-cli; resolve dependency errors by installing plugin versions that declare the new core as requiredCore. Test the vendor job plus a representative Pipeline and freestyle job. Java 17 is a separate gate: do not switch the controller JVM until the vendor certifies it. If the target LTS has dropped Java 11 and the vendor has no Java 17 build, the migration is blocked; options are replacing the plugin, running the vendor tool in a container from a Pipeline step while removing the plugin from the controller, or delaying. Rollback is restoring JENKINS_HOME, the previous Java, and the service unit, then verifying a sample build.
2. Explain the likely causes of the plugin dependency error and the 'No such DSL method' failures, and how you would confirm each before changing production.
Read the worked answer
The dependency error means a plugin manifest requires a newer core or a different plugin version, or a partial download left an inconsistent .jpi. Check the controller log, $JENKINS_HOME/plugins/*.jpi.disabled, and the plugin manager JSON (/pluginManager/api/json?depth=1) for requiredCore and dependencies. The DSL error is usually a step contributed by a plugin that failed to load or is disabled, or a shared-library global variable that is missing; it is not fixed by wrapping the call in script. Confirm by running a minimal Pipeline that calls the method and by comparing active plugin lists between clone and production. Use the Script Console to list Jenkins.instance.pluginManager.plugins and check workflow-cps, workflow-job, and the plugin that supplies the step. Install compatible versions on the clone, restart, and re-run the minimal Pipeline before touching production.
3. What concrete steps recover disk space on JENKINS_HOME without losing audit evidence, and how do you validate the rollback?
Read the worked answer
Measure first: du -sh $JENKINS_HOME/jobs/* and find large builds/*/archive directories. Old build records and artifacts are usually the bulk, plus old exploded war directories and controller workspaces. Add buildDiscarder(logRotator(numToKeepStr: '30', artifactNumToKeepStr: '10')) to jobs and folder defaults, then run a one-time cleanup with a reviewed script or the Jenkins API; do not rm -rf active builds. Move builds off the controller with agent any and clean workspaces with cleanWs(). Archive long-term artifacts outside Jenkins (S3 or Artifactory) if retention requires them. Validate rollback by restoring the backup to a clone, starting with the same Java, and checking that jobs, credentials, and a sample build work. Add disk alerts at 75% and 85%.