A shared pipeline code library is versioned, reusable automation for work that many pipelines need to perform. It lets teams standardize common steps and cross-functional requirements without copying their implementation into every repository. CircleCI orbs and GitHub Actions shared actions and workflows are examples. section 6.2.2
Keep each team's pipeline definition in its repository and make it responsible mainly for triggers and job orchestration. Put reusable logic in shared code that the pipeline references directly. Installing plugins on a pipeline server or runner is not equivalent: it makes the pipeline depend on separately maintained infrastructure and can make it brittle. section 6.2.2 section 6.5
A practical library design balances consistency with team control:
- Start with a repeated operation, then package the steps as a reusable job or action rather than duplicating them across pipelines. section 6.3.7
- Expose parameters and optional insertion points so teams can adapt a standard job without replacing it wholesale. section 6.3.7 section 6.5
- Treat the library like other shared software: apply appropriate security practices, integration-test it, and publish versioned releases. section 6.2.2
A reusable infrastructure plan job
A CircleCI job can check out code, run `terraform init`, produce a `terraform plan`, and optionally run a Checkov scan. The repository pipeline selects when that job runs; the shared job holds the repeatable procedure. Parameters such as the working directory and plan output path let different repositories use it. section 6.3.7 section 6.5
after-checkout: description: Optional steps to run after checking out the repository code. type: steps default: [] after-init: description: Optional steps to run after running terraform init. type: steps default: [] after-plan: description: Optional steps to run after running terraform plan. type: steps default: [] after-complete: description: Optional steps to run after the entire plan job is complete. type: steps default: []
The optional `after-checkout`, `after-init`, `after-plan`, and `after-complete` step parameters show how a standard job can leave defined places for repository-specific work. section 6.3.7
