Some monorepo teams generate the CI pipeline from the affected package set instead of writing every job statically. What does that buy, and what does it cost?

## Two ways to make a monorepo pipeline proportional Once a monorepo has more packages than anyone wants to build on every commit, the pipeline has to shrink to fit the change. There are two structurally different ways to do that. **Statically, with conditions.** Write a job for each package and attach a condition to each — a path rule, or a check against a precomputed affected list. All jobs exist in the definition; most do not run. **Dynamically, by generation.** Run one small job first. It resolves the diff base, computes the affected set, and writes out a pipeline definition containing only the jobs those packages need. The platform then runs that generated definition as a child pipeline. Most major CI platforms support some form of this — a generated child pipeline, a dynamically produced configuration, an uploaded pipeline definition — under different names. ## What generation genuinely buys **The pipeline is proportional to the change, not to the repository.** With fifty packages, a one-package change produces a run with a handful of jobs, not fifty entries of which forty-eight are skipped. That matters for readability more than for cost: a run page that lists only real work is one a human can actually read. **Per-package variation without duplication.** Packages are not uniform — some need a database service, some need a longer timeout, some need a browser. Expressing that statically means fifty hand-maintained blocks that drift. A generator expresses it once as logic over package metadata. **New packages are free.** Add a package, and the generator emits its jobs on the next run. In the static model, someone must remember to add a block, and the failure when they forget is silent — the package simply has no CI. **Work that is only knowable at run time.** Sharding a test suite across N containers where N depends on how many affected packages there are, or splitting by recorded timings, cannot be written down ahead of time. ## What it costs **The definition leaves the repository.** In the static model the reviewer of a pull request sees the pipeline change in the diff. In the generated model they see a change to the program that produces pipelines. The actual definition for any given commit exists only as generator output, and the reasoning "what will this run do?" becomes "what will this program emit?". **Generator bugs are a new failure class.** A template that emits subtly invalid configuration, an escaping bug in an interpolated package name, an off-by-one in a shard count. Some of these fail loudly at pipeline-parse time; the dangerous ones emit a *valid* pipeline that quietly omits a job. That is the same silent-skip class as a wrong diff base, arriving by a different route. **Debugging is indirect.** "Why did this job not run?" requires reproducing the generator against that revision, which means the generator needs to be runnable locally and its output needs to be persisted with the run. Teams that skip persisting the generated definition make every such investigation archaeology. **Reporting fragments.** Status, timings and logs live across a parent run and one or more children. Anything that aggregates pipeline data — dashboards, flake tracking, duration trends — needs to understand the parent/child relationship, and tooling that assumes one run per commit needs adapting. **Setup latency.** Every run pays for the setup job before anything useful starts: a checkout deep enough to resolve the base, the affected computation, then emitting and starting the child. On a small change that overhead can rival the work itself. ## Choosing between them A reasonable progression: start static while the package count is small and the jobs are uniform. Move to generation when either the number of packages makes the static file unreadable, or per-package variation makes it repetitive, or you need run-time-determined fan-out. A hybrid is common and often best: keep a static skeleton for the things that always run — lint, the repository-wide checks, the security scan, the deploy stage — and generate only the per-package build-and-test fan-out. That keeps the reviewable parts reviewable and confines generation to the part that genuinely varies. Whatever you choose, treat the generator as production code: it is under test, its output is persisted with each run, and it fails closed. A generator that emits an empty pipeline on an internal error must be an error, never a fast green run.