Jenkins Shared Libraries
Enforce DRY (Don't Repeat Yourself) pipeline engineering by centralizing re-usable Groovy logic, custom build steps, and standardized corporate automation patterns.
What are Shared Libraries?
As organizations scale out hundreds of application deployment pipelines, copying and pasting similar pipeline configurations across code repositories leads to management failure, configuration drift, and security auditing blindspots.
Jenkins Shared Libraries provide a centralized mechanism to share modular Groovy code across completely distinct pipelines. Stored inside an external Git repository, these libraries allow platform teams to construct unified corporate pipeline frameworks, encapsulate complex shell invocations, and mask specialized logic behind simple, single-line global step commands.
Standard Layout & Execution
Directory Blueprint Architecture
Shared repositories must match a strict three-tier layout: `src/` for classic object-oriented Groovy helper classes, `vars/` for custom global steps and variables exposed directly to pipelines, and `resources/` for static file assets (JSON schema, XML config templates).
Dynamic Version Scoping
Pipelines import libraries via a version specifier, such as a Git tag, branch, or specific commit hash (`@Library('my-lib@v1.2.0')`). This isolates pipelines from unvetted updates and breaks, allowing controlled blue-green framework evolution.
Global Variable Custom Steps
Any Groovy script saved within the `vars/` directory defines a globally accessible method matching the filename. Defining a `call(Map config)` block inside `vars/buildApp.groovy` allows multiple applications to use `buildApp(type: 'maven')` seamlessly.
Implicit vs. Explicit Inclusion
Libraries can be marked as *Load Implicitly* within system administration configurations to run automatically on all pipelines, or they can be declared explicitly inside specific Jenkinsfiles via the `@Library` annotation block.
Shared Library Implementation Blueprint
Below is an enterprise configuration pattern showing a custom global step definition file, alongside a declarative `Jenkinsfile` consuming that custom wrapper step:
1. Custom Global Variable Step File (`vars/standardNotify.groovy`)
// vars/standardNotify.groovy
def call(Map config) {
def status = config.get('status', 'SUCCESS')
def channel = config.get('channel', '#ci-alerts')
echo "Sending standardized enterprise notifications to \${channel}..."
if (status == 'FAILURE') {
echo "[ALERT] Execution failure detected! Notifying platform operations."
// actual slackSend or email steps would be placed here
} else {
echo "[INFO] Execution terminated successfully."
}
}
2. Declarative Pipeline Consuming the Variable
@Library('enterprise-pipeline-framework@v3.1') _
pipeline {
agent any
stages {
stage('Compile & Test Execution') {
steps {
echo 'Running basic building processes...'
}
}
}
post {
success {
// Invoking our custom global step directly from the library
standardNotify status: 'SUCCESS', channel: '#delivery-stream'
}
failure {
standardNotify status: 'FAILURE', channel: '#delivery-stream'
}
}
}
Shared Library Exercise
- Explore Global Library Declarations: Go to Manage Jenkins → System, scroll down to the Global Pipeline Libraries section, and analyze the configured backing Git repositories.
- Build a Mock Global Variable: Create a dummy code structure with a file path of `vars/sayHello.groovy` containing a basic `def call() { echo 'Hello World' }` statement.
- Verify Runtime Library Compilation: Create a pipeline referencing your framework repo via `@Library`, trigger the execution loop, and inspect the top of the Console Output log to trace the library checkout.
- Investigate Sandboxing Controls: Intentionally invoke non-sandboxed Java methods (e.g., file writing helpers or runtime executions) inside a shared script to observe how the engine handles script approval challenges.
Summary
You have completed the Shared Libraries architecture module. You now possess the foundational knowledge required to encapsulate structural execution patterns, prevent pipeline script duplication, and deploy consistent build engines at enterprise scale. Proceed to the next topic to manage code-based cluster orchestration via configuration as code.