Implementation guide
Run only affected tests safely
Compare changed-path rules, task graphs, and source dependencies; define full-suite triggers before measuring a selection.
Implementation and evaluation
Change-aware CI guides grounded in measured evidence.
Start with the decision you need to make: how to identify affected tests, how to preserve GitHub Actions prerequisites, or how to decide whether a narrower run saves any money.
Start with the implementation boundary
GitHub Actions
Preserve the job that CI actually runs
Model checkout history, installation, generation, services, matrices, and always-run checks instead of selecting test files in isolation.
Support matrix
Know what the analyzer can resolve
See the implemented JavaScript/TypeScript, Vue, Go, and Maven boundaries—and the cases that deliberately require full validation.
Strategy comparison
Path filters, task graphs, or source selection?
Choose the cheapest maintainable evidence model that remains conservative for the repository in front of you.
Evaluate economics separately from safety
CI economics
Measure GitHub Actions cost
Separate test-stage time, job-equivalent runtime, workflow latency, and billed compute before claiming a saving.
Open data
Inspect the benchmark and its failures
Download the evidence, see where a cheap path baseline won, and keep withheld or unhonored selections visible.
Measured case study
cal.com replay
See why an 86–91.6% test-stage reduction became 44.2% after install and pretest cost were included.
Measured case study
deepseek-harness replay
See 79.5–89.5% counted job-level reductions and the run withheld because execution did not honor the proposed selection.
Try one observation before changing CI
Analyze the current checkout without executing tests or sending a report:
npx "@diffci.com/diffci@latest" observe --no-sendUse check only when repository test commands are allowed to run. A fallback is useful evidence that the change could not be narrowed safely; it is not a reason to remove required CI.