Core, Plugins, and Upgrade Strategy

Scenario: Dozens of plugins are updated directly before a critical release and a resumable Pipeline breaks.

Pipeline example

pipeline { agent any; stages { stage('Upgrade smoke suite') { steps { build job: 'pipeline-smoke-tests' } } } }

Upgrades change a dependency graph

Plugins declare minimum core and plugin dependencies, and optional integrations add edges. Updating one visible plugin can transitively alter credentials, SCM, Pipeline, or serialization behavior. Export installed versions, read upgrade guides and advisories, inspect dependency changes, and remove truly unused plugins. Every installed plugin adds code, configuration, startup cost, and compatibility constraints.

Build staging from the same pinned controller configuration and representative restored jobs. Test authentication, RBAC, agents, webhooks, credentials, Pipeline creation, paused input, restart/resume, JUnit, artifacts, and notifications. A healthy login page does not validate build compatibility. Back up before migration and account for plugin data changes in rollback.

Canary with operational evidence

Pin controller image, Java, core, and plugins in reviewable code. Drain or account for running work, avoid critical releases, and capture queue and executor baselines. After rollout watch startup errors, configuration-as-code rejection, remoting, queue reasons, Pipeline exceptions, and login failures.

Keep a tested previous image and restore procedure. An urgent security fix may shorten the window but does not remove the need to understand exposure, affected permissions, smoke tests, and rollback criteria.

Goal: Practice the concrete behavior in jenkins-declarative-rescue. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.