vars, src, resources, and Loading

Scenario: Fifty repositories copy the same deployment helper and patch a security defect at different speeds.

Pipeline example

@Library('delivery-lib@3.4.1') _
pipeline { agent any; stages { stage('Verify') { steps { companyVerify() } } } }

Libraries expose three surfaces

Files in vars expose global steps by filename and optional matching text documentation. Src follows package structure for Groovy classes on the Pipeline classpath. Resources contains static templates read with libraryResource. Runtime code should orchestrate Jenkins steps instead of growing into an application framework or using controller internals.

The Library annotation loads a configured library before compilation, enabling imports and global variables. The dynamic library step loads later and cannot retroactively add normal imports to already compiled source. Jenkins resolves an SCM retriever and requested version; record the actual revision because mutable defaults can change an unchanged application build.

Create small, restart-safe APIs

A companyVerify step should accept named arguments, validate them, call visible Pipeline primitives, and return simple serializable data. Avoid stateful global objects and values that cannot cross CPS suspension. Unit-test validation and step calls, then integration-test real agents, credentials, failures, and controller restart.

Keep application-specific settings in the consuming repository. Centralize stable organizational policy and safe repeated orchestration. A library earns its cost when it makes a security correction or operational contract consistent across consumers, not merely when it removes a few readable Jenkinsfile lines.

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.