Monorepo pipeline
What it is
A monorepo pipeline is the CI strategy applied to a single repository that houses many logical projects/apps — each project often needing its own build/test/release, sometimes under the same pipeline. The challenge is that one repo holds many independent units, so one monolithic run would be wasteful and one “all-or-nothing” gate brittle.
Why it exists
Growing teams often keep a single codebase (shared infrastructure, one history, cross-project refactors) but still need per-project CI. Monorepo pipelines exist to run only the subtrees that changed and validate each project independently — keeping the repository unified without forcing every change to pay for every suite.
Key ideas
- Path-scoped triggers: trigger a run only when files under a given directory change (
paths,paths-ignore,trigger.filesChanged). - Many pipelines per repo: separate pipelines/workflows per logical project, each watching its folder.
- Shared infrastructure: one repo → one PR stream, consistent review, and a single version-of-truth (see pipeline-run).
- Downside to plan for: a change that touches shared code can fan out to many pipelines; large clones/slow scans; protection needs organised.
How it fits (diagram)
Exam notes
- Know the path-filter serialization (
paths-ignorevspaths) — a frequent hook question. - A monorepo often pairs with matrix builds or a single pipeline with
if: changes()in GitHub. - It is a repo-topology concept — distinct from a pipeline authoring concern and from multi-repo CI.
Related
ci-trigger · pipeline-run · github-actions · azure-pipelines
📘 Source: Azure Pipelines trigger paths & branches · GitHub workflow events (paths filter)