Run only the tests a change can affect

Use dependency or observed-file relationships to select affected tests, with a full-suite fallback for changes the selector cannot classify.

View in Markdown

Prompt

Evaluate and apply this CI technique to my repository: Run only the tests a change can affect.

Use dependency or observed-file relationships to select affected tests, with a full-suite fallback for changes the selector cannot classify.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/select-affected-tests.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How it works

Start with the files changed in a pull request, then use the repository’s dependency graph or recorded file usage to identify the tests and build targets that depend on them. Run that affected set for scoped changes. Keep the full-suite path for changes the selector cannot safely classify. The examples below use different selectors, so choose the one that matches your repository’s tooling.

How companies used this technique

Read what each company changed and follow the original sources.

Run only affected tests

Translated to GitHub Actions

What Anthropic built: Anthropic's test selection service determines which tests run on each change.
Your GitHub Actions version: Scope the slowest build or test job to the changed packages and their dependents.

Anthropic picks which tests run on each pull request from package relevance and past results. In GitHub Actions, the same idea scopes the slowest build or test job to the changed packages and their dependents.

Use it when: The merge-gating build or test step dominates and existing tooling can compute affected targets.
Before applying it: The scoper falls back to the full suite on an error or an empty result, and the default branch and merge queue keep their full runs.
GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation.

Route tests through the dependency graph

Mastra evolved from task hashes to a symbol-aware import graph. Runtime and type-test dependencies require separate treatment. This adapts changed-package filtering to test-file selection.

Use it when: A monorepo repeatedly tests unrelated packages for small changes.
Before applying it: Follow-ups repaired exported subpaths, merge-base comparisons, Vitest project discovery and JavaScript Vitest configs. Release PRs and alpha publishes run the full suite. Unknown inputs expand to the full suite.

Build only the data models a change modified

Ramp's data CI created an isolated database for each pull request and built every dbt model in it, a full duplicate of production. After each production run, Ramp now saves dbt's manifest.json, and CI builds with --select state:modified+1 against it. Heavy upstream models are cloned from production with zero-copy clones, so CI builds and tests only the modified models and their direct downstream dependencies. The OPT70 recipe scopes a build to changed targets; here the comparison is against the saved production state.

Ramp saw a dramatic dip in the rolling 7 day average cost of its CI warehouses, mostly sustained as pull request volume grew. Source

Use it when: CI builds or tests every model, package or target on each pull request, and the tool can select by state against a saved artifact.
Before applying it: The selection is only as current as the saved state, so save the artifact after every production run and keep a full build on the default branch or a schedule.

Run only the tests a change can reach

Translated to GitHub Actions

What Stripe built: Stripe instruments its Ruby test runner so every file a test opens is recorded against that test, then reruns the tests whose recorded files changed.
Your GitHub Actions version: Record the files each test reads, compare the change's file inventory with a recent completed build, and rerun only the tests whose files changed, always including previously failing tests.

Stripe instruments its Ruby test runner so every file a test opens is recorded against that test, including files opened by child processes. For a new change it hashes the file inventory, compares it with a recent completed build and reruns the tests whose recorded files changed. Guardrails always rerun previously failing tests and tests that discover files by globbing, and linters receive the changed-file list.

On average Stripe runs roughly 5% of its full Ruby test suite per build, with a median of 0.5%, using under 10% of the compute of running everything. Source

Use it when: A large suite runs in full on every change while most changes touch a small part of the code.
Before applying it: Selection is only as complete as the dependency signal. Keep full runs on the default branch, always run tests whose inputs are discovered at runtime, and rerun every test that was red last time.
GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation.

Select changed modules and their dependents

Stripe iOS re-records snapshots only for modified modules and the modules that depend on them, walking Xcode target links including shared test utilities. SDK size reports check only affected SDKs and their dependents. When the selection is uncertain, both run in full.

In Stripe’s combined CI runs, framework tests went from about 22 to about 12 to 14 minutes, and snapshots and localization from about 15 to about 13 to 14 minutes, with the related build and job changes. Source

Use it when: A monorepo rebuilds and tests modules unrelated to a change.
Before applying it: Shared configuration, generated inputs and test utilities can affect untouched modules. Run the full set for anything the graph leaves unplaced, and keep full validation on the default branch.

How it works

How companies used this technique

Run only affected tests

Route tests through the dependency graph

Build only the data models a change modified

Run only the tests a change can reach

Select changed modules and their dependents

Related techniques

After the first full agent scan, review only what changed

Install and build only the workspace packages a job uses

Move selected heavy checks after merge

Company Playbooks

Related guides

Build and test only what changed

Cancel superseded CI runs

Cut CI queue time

Filter workflows by changed files