A pipeline is a defined arrangement of automation jobs that runs as a coordinated process. In a repository, its configuration should primarily decide when work runs and which jobs run before others. Keep the detailed work in shared, versioned code or local scripts rather than embedding it throughout the pipeline. section 6.3.7
A source-code change is the usual trigger; a nightly build or integration test can also be useful. Jobs can run in sequence when one requires another to finish, or in parallel when they do not. Filters narrow when individual jobs run—for example, only after a tag is added or a change reaches the main branch. Avoid having a pipeline trigger another repository’s pipeline as a routine coordination mechanism: that can couple the repositories in unhealthy ways. section 6.3.7
on-push-main: &on-push-main
branches:
only: /main/
tags:
ignore: /.*/
…
workflows:
jobs:
my-job:
filters: *on-push-main
This CircleCI configuration reuses one YAML anchor to apply a main-branch, no-tags filter to a job. It illustrates how a local pipeline can express when to run without duplicating trigger rules. section 6.3.7
Reuse should extend beyond individual commands. Shared pipeline code can provide versioned jobs while allowing teams to inject custom steps, override parameters, or adapt tool versions. This keeps common behavior maintainable without forcing every repository into an identical implementation. Developer ownership of pipeline code, secure debugging access, and attention to performance help keep that automation usable. section 6.3.7 section 6.5
Start small, then split ownership
A small platform team can initially orchestrate cluster-wide control-plane applications through one or two pipelines, grouped as services or extensions. This helps it support early customers while reducing overlapping maintenance work. As the platform scales, lifecycle pipelines for individual services and extensions can improve release quality and remove bottlenecks; dynamic pipelines can adapt deployments to the number and configuration of clusters. section 8.1 section 9.4
Verify an upgrade without a manual check-in
When a cluster component is upgraded in a preview environment, an application team’s conformance test pipeline can deploy and test its current version. A consumer API can trigger the workflow through the team’s CI webhook. Passing tests may require no developer action; failures can add logs and pipeline links to a Jira ticket, giving the team a concrete starting point for a fix. section 9.3.4
Not every pipeline runs delivery jobs. An observability system can use separate ingestion pipelines for metrics, logs, and traces; ingestion APIs validate and format each data type before storing it in its corresponding backend. In both cases, the pipeline makes a repeatable process explicit, but its steps and destination depend on the work being coordinated. section 5.1.4 section 6.3.7
