What Is a Parent-Child Pipeline? Splitting a Big Pipeline
A parent-child pipeline breaks a large pipeline into a parent that triggers one or more child pipelines, usually one per component or area.
A single pipeline file describing everything a big repo does becomes unreadable and slow to maintain. The parent-child pattern splits it: a small parent pipeline decides what changed and triggers focused child pipelines for the affected components. Each child is simpler, and unaffected components do not run.
How the split works
The parent pipeline runs first and acts as a dispatcher. It can inspect what changed and dynamically trigger only the relevant child pipelines, each of which is a self-contained pipeline for one part of the codebase.
Why split this way
- Smaller, readable config per component.
- Run only the children affected by a change.
- Teams own their child pipeline independently.
A quick example
In a monorepo with frontend/, backend/, and infra/, the parent detects which folders changed and triggers only those child pipelines. A docs-only change skips the backend and infra children entirely.
Parent-child vs downstream
Parent-child pipelines usually live in the same project and are split for organization. A downstream pipeline often crosses into another project. The mechanics overlap, but the intent differs: structure versus cross-project chaining.
Cost benefits
Because unaffected children do not run, this pattern trims wasted compute in large repos. Combined with metered runners (Latchkey), you can see how much each child pipeline costs and prune the ones that rarely catch anything.
Key takeaways
- A parent-child pipeline splits a big pipeline into a dispatcher plus children.
- The parent triggers only the child pipelines affected by a change.
- It keeps config readable and avoids running unrelated components.