Monorepo CI

The naive CI for a monorepo is the same as for a regular repo: run the full test suite on every PR. This works fine for the first dozen projects. It stops working somewhere between 50 and 100, when the bill and the wait time both pass the threshold of "what we are willing to pay for a typo fix to land."

The cost shows up in two places:

• CI minutes: a typo fix in one project rebuilds and re-tests every project. Multiply by team size and PR rate, and the bill becomes a top-five infrastructure cost.
• Engineer wait time: a 60-minute CI suite blocks every PR, even the ones that should have taken thirty seconds.

The point of monorepo CI is to make the cost of a PR proportional to the size of the change, not to the size of the repo.

The core idea is the project graph. Each project declares the files it depends on (source, configuration, shared libraries). A change is a diff. Given the diff, walk the graph backward to find every project that depends on any changed file. That set is what needs to be re-tested. Everything else is skipped.

Common ways to express the graph:

• Bazel: BUILD files declare inputs and deps. bazel query walks the graph. Strong determinism, high operational cost.
• Nx: implicit graph derived from imports plus an explicit project.json. nx affected is the query. Strong fit for JavaScript and TypeScript monorepos.
• Turborepo: similar shape to Nx, lighter touch. turbo run --filter drives the affected set.
• Pants: the Bazel-shaped option for Python-heavy monorepos.
• Hand-rolled: a script that maps top-level directories to projects and uses git diff --name-only. Plenty of teams ship this for a year before they hit the limits.

The tool matters less than the discipline of declaring project boundaries. Once the boundaries exist, any of these tools can compute the affected set.

Affected-projects detection makes PR CI fast. The other half of the puzzle is the merge queue. A naive single-queue setup serializes every merge in the repo, so a frontend PR waits behind a backend migration that has nothing to do with it. The bigger the repo, the worse the bottleneck.

The fix is independent merge lanes per scope. The queue understands which project a PR touches and runs lanes in parallel. PRs that touch a single scope live in that scope's lane. Cross-cutting PRs that touch two scopes join both lanes and merge only after passing each. This is what makes a merge queue scale to a real monorepo without becoming a serialization tax.

Mergify supports this pattern natively. Scopes are declared once, the queue runs parallel lanes per scope, and batching is scope-aware so unrelated PRs do not contaminate each other's batches. For the per-product detail, see Mergify Merge Queue and the parallel queues guide.