Unlocking Jenkins Power: Extending with Shared Libraries

In the world of Jenkins, Shared Libraries exist to solve a common problem: code duplication across multiple pipelines. Instead of rewriting the same logic for each pipeline, you can define a Shared Library that encapsulates this logic in one place. This not only saves time but also ensures consistency across your CI/CD processes.

Shared Libraries are defined with a name and a source code retrieval method, typically through SCM. You can load these libraries into your pipelines during compilation, allowing you to use their functionality right away. There are two main types: Global Shared Libraries, which are accessible from any pipeline, and Folder-level Shared Libraries, scoped to specific folders. You can load libraries implicitly, which allows immediate access to classes or global variables, or specify a default version if needed. For example, you can load a library with @Library('my-shared-library') _ or specify a version with @Library('my-shared-library@1.0') _.

However, be cautious when using Shared Libraries. Anyone with commit access to the SCM repository can potentially gain unlimited access to your Jenkins instance. Additionally, avoid importing global variables or functions directly, as this can lead to unintended static interpretations. As of version 2.7 of the Pipeline: Shared Groovy Libraries plugin, there’s an option for loading non-implicit libraries, which adds flexibility to your pipeline scripts.