Your monorepo's CI runs the full test suite on every pull request, and it now takes forty minutes regardless of whether someone touched one file or a hundred. How would you fix that?
4 min readUpdated 2026-08-15
0
Answer
Short answer
Build a dependency graph of the repository's build targets, diff the changed files against it to compute the affected subset, and run only that subset; the graph's correctness, not the diff itself, is what determines whether the speedup is trustworthy.
Was this answer helpful?
Likely follow-ups
→How would you handle a change to a shared configuration file or a build tool version, which nothing depends on explicitly but which can break everything?
→What would make you distrust the affected-target result for a given PR and fall back to running everything?
→How would you test the graph itself for correctness, separately from testing the code it describes?
→How does this interact with a merge queue, where several PRs land close together and each recomputes an affected set against a slightly different base?
Running everything is a heuristic that just happens to be safe
Running the full suite on every change is not a design choice, it's the absence of one: it's correct by construction, because nothing that could possibly be affected is skipped, and its cost simply scales with the size of the whole repository regardless of the size of the change. That property is exactly what makes it wrong for a large monorepo. A one-line fix to a leaf module pays the same forty minutes as a change touching a dozen shared libraries, and the wait time has stopped correlating with the size of the actual risk.
The fix that actually reduces the number without reducing safety is to build a model of which targets depend on which other targets, and use that model to compute the specific subset of the repository that could possibly be affected by a given change. Everything else about the problem follows from how good that model is.
Building the graph, and where its accuracy actually comes from
A build graph, in this context, is a set of nodes — packages, modules, or build targets — and edges representing "depends on." Most build systems that support this (Bazel, Nx, Turborepo, and others each have their own name for it) construct the graph from declared dependencies: import statements, explicit dependency manifests, or a target's declared inputs. Given a set of changed files, you can map each file to the target that owns it, then walk the graph outward to every target that transitively depends on an owning target.
Change: a single file inside package `auth-core`
auth-core <- directly changed
^
|-- api-gateway (depends on auth-core)
| ^
| |-- checkout-service (depends on api-gateway)
|
|-- admin-portal (depends on auth-core)
Affected set: auth-core, api-gateway, checkout-service, admin-portal
Not affected: everything else in the repository, however large it is
The subtlety worth stating explicitly is that you need the transitive closure, not just direct dependents. checkout-service doesn't import auth-core at all — it depends on api-gateway, which does — but a change to auth-core can still break it, and stopping the walk at one hop silently drops it from the affected set.
Where affected-target detection actually goes wrong
The dangerous failure mode isn't slowness, it's a false negative: a target that was genuinely affected but wasn't included in the computed set, so it never runs and a regression ships untested. This happens whenever the graph doesn't capture a real dependency. A shared configuration file loaded at runtime rather than imported at build time, a database migration that several unrelated services rely on implicitly, or a build-tool version bump that changes compiled output for everything — none of these show up as an edge in a graph built purely from import statements, so a change to any of them computes an affected set that misses everything it should have included.
Loading diagram…
The practical mitigations are to explicitly model the dependency types the import graph can't see — declaring that every target depends on the shared config file, even though no code imports it — and to treat certain classes of change, such as a build tool or base image bump, as always triggering a full run regardless of what the graph computes. Neither is a complete fix; both reduce the surface area of the blind spot.
Trusting the speedup without trusting it blindly
Because a false negative here is a correctness bug that ships silently rather than a build failure that's immediately visible, an affected-targets system needs a way to catch its own mistakes over time, not just on the day it's built. Running the full suite periodically — nightly, or on every merge to the main branch rather than on every PR — and treating any discrepancy between what the full run and the affected-subset run would have caught as a bug in the graph, is what keeps the model honest as the codebase and its real dependencies evolve.
The trade a team is actually making by adopting this isn't "faster CI for the same safety." It's faster CI for the same safety on changes the graph models correctly, and a periodic full run as insurance against the changes it doesn't. Stating that distinction is usually the difference between a candidate who has operated one of these systems and one who has only read about the speedup.
The forty-minute problem is solved by the graph, but the graph's blind spots are what determine whether the fast path is actually safe rather than merely fast.