Affected-Project Detection measures the ability to accurately determine which projects, services, or build targets are impacted by a given code change, particularly in monorepo environments. Effective detection enables targeted CI runs, scoped testing, and informed risk assessment without rebuilding or retesting the entire repository. Poor detection leads to either wasteful full-repo builds or dangerous gaps where affected services are not validated.
Accuracy of determining which projects are impacted by a code change. Without it, every change triggers full-repo builds/tests.
THE #1 MONOREPO-SPECIFIC METRIC. Nx, Bazel, and Pants analyze dependency graphs to determine exactly which projects need rebuilding. Nx reports 90-95% CI time savings. If this metric is poor, nearly all other monorepo metrics degrade catastrophically.
Monorepo-specific: without affected-project detection, every change triggers full-repo builds. Nx reports 90-95% CI savings. Only matters at scale.
Accurate detection means only affected projects build/test. Nx reports 90-95% CI time savings. Without it, full-repo builds on every change.
Only affected tests run. Google: tests only run if transitive dependency graph includes changed files.
Devs don't wait for unrelated builds. Fast feedback on their actual changes.
Queue partitioning: PRs only compete with PRs affecting the same projects, not all PRs.
Fewer tests run = fewer opportunities for flaky failures per PR.
Accurate detection → building the same targets → higher probability of cache hits.
Larger repos have more complex dependency graphs, making accurate affected detection harder.
Tangled cross-project dependencies (circular deps, god packages) explicitly break the Directed Acyclic Graph (DAG) required by Bazel/Nx, forcing full-repo rebuilds.