--- title: "Skip jobs whose inputs have not changed" description: "Gate expensive workflows and jobs on the files they consume, keeping required check behavior intact." url: https://starsling.dev/ci-playbooks/techniques/skip-unaffected-jobs canonicalUrl: https://starsling.dev/ci-playbooks/techniques/skip-unaffected-jobs --- # Skip jobs whose inputs have not changed Gate expensive workflows and jobs on the files they consume, keeping required check behavior intact. ## How to choose an approach Compare the examples by repository setup, prerequisites, and risks before adopting one. Each company implemented this in its own environment; measure each change against your own baseline. - **[Anthropic](https://starsling.dev/ci-playbooks/anthropic#path-filters)**: Use it when An expensive workflow runs for unrelated files, or app-specific jobs ignore the dependency graph. Check before adopting: Required checks stay reachable: a changes job with job-level conditions keeps a skipped job reporting success. Adapted for GitHub Actions; compare the original system with yours. - **[DoorDash](https://starsling.dev/ci-playbooks/doordash#gate-native-matrix)**: Use it when An expensive matrix verifies one subsystem and runs on every change to the repository. Check before adopting: The path list must cover every input: source, shared packages, lockfiles and the workflow file itself. Required checks must still report when the matrix skips. - **[Mastra](https://starsling.dev/ci-playbooks/mastra#affected-jobs)**: Use it when A workflow serves several independent packages or checks with distinct inputs. Check before adopting: Workflow files, shared config, dependency changes and routing-tool changes can affect every target. Keep required status reporting and treat invalid routing artifacts as full coverage. - **[OpenAI](https://starsling.dev/ci-playbooks/openai#scope-independent-jobs)**: Use it when Edits to existing test modules launch unrelated SDK, packaging or container work. Check before adopting: Independence needs more than path names: added, deleted, renamed, shared-helper and mixed changes run the full set. - **[Shopify](https://starsling.dev/ci-playbooks/shopify#filter-platform-consumers)**: Use it when A monorepo starts every platform job for changes confined to one generated binding. Check before adopting: Shared schemas, generators and lockfiles reach several languages, so they map to every consumer. - **[Shopify](https://starsling.dev/ci-playbooks/shopify#skip-docs-only)**: Use it when Documentation edits start expensive platform suites that build and test only source code. Check before adopting: A workflow skipped at the trigger never reports its required checks; filter at the job level so the checks still report. - **[Stripe](https://starsling.dev/ci-playbooks/stripe#skip-unrelated-checks)**: Use it when Documentation or unrelated changes trigger an expensive, narrowly scoped check. Check before adopting: A whole-workflow path filter can leave a required check pending. An always-present gate that reports a no-work result keeps branch protection intact; include global build inputs in the scope. ## Apply this technique ````text Evaluate and apply this CI technique to my repository: Skip jobs whose inputs have not changed. Gate expensive workflows and jobs on the files they consume, keeping required check behavior intact. Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/skip-unaffected-jobs.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. ```` ## How companies used this technique Read what each company changed and follow the original sources. ### Anthropic: Skip workflows a change cannot affect **Translated to GitHub Actions** - What Anthropic built: Anthropic runs a selected set of tests on each pull request. - Your GitHub Actions version: Path and job-level filters that keep expensive workflows to changes in the files they depend on. Anthropic runs a selected set of tests on each pull request. In GitHub Actions, path and job-level filters keep expensive workflows to changes in the files they depend on. Evidence: Documented technique Use it when: An expensive workflow runs for unrelated files, or app-specific jobs ignore the dependency graph. Before applying it: Required checks stay reachable: a changes job with job-level conditions keeps a skipped job reporting success. GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation. [Read more in the Anthropic playbook](https://starsling.dev/ci-playbooks/anthropic#path-filters) [Primary source](https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic) ### DoorDash: Start the native matrix when its inputs change The self-update PR added native updater journeys on macOS arm64, macOS Intel and Linux arm64. A step in the test job diffs the change against its base and sets an output; the native matrix runs when that output is true. When the checkout lacks the base commit, or the run is a manual dispatch, the matrix runs. Linux amd64 runs the complete process suite on every change. Evidence: Source PR/commit evidence Use it when: An expensive matrix verifies one subsystem and runs on every change to the repository. Before applying it: The path list must cover every input: source, shared packages, lockfiles and the workflow file itself. Required checks must still report when the matrix skips. [Read more in the DoorDash playbook](https://starsling.dev/ci-playbooks/doordash#gate-native-matrix) [Primary source](https://github.com/doordash-oss/agentic-orchestrator/pull/180) ### Mastra: Skip whole jobs only when their inputs are unchanged Mastra gated AGENTS and peer-dependency validation by relevant inputs and generated workspace matrices from affected packages. Job-level conditions and validated matrices sit on top of trigger-level paths filters. Evidence: Source PR/commit evidence Use it when: A workflow serves several independent packages or checks with distinct inputs. Before applying it: Workflow files, shared config, dependency changes and routing-tool changes can affect every target. Keep required status reporting and treat invalid routing artifacts as full coverage. [Read more in the Mastra playbook](https://starsling.dev/ci-playbooks/mastra#affected-jobs) [Primary source](https://github.com/mastra-ai/mastra/pull/22381) ### OpenAI: Skip independent jobs only for proven narrow edits For modifications to existing top-level pytest modules, Codex Security keeps all five Python jobs and the checks that depend on them, and skips the independent SDK, Windows install, Action and eval jobs. A related change also skips container jobs once it proved those modules sit outside the image's build context. Evidence: Source PR/commit evidence Across seven earlier PRs that only edited existing pytest modules, the jobs this route skips used 17h29m53s of runner time (139 jobs) ([Source](https://github.com/openai/codex-security/pull/2002)) Use it when: Edits to existing test modules launch unrelated SDK, packaging or container work. Before applying it: Independence needs more than path names: added, deleted, renamed, shared-helper and mixed changes run the full set. [Read more in the OpenAI playbook](https://starsling.dev/ci-playbooks/openai#scope-independent-jobs) [Primary source](https://github.com/openai/codex-security/pull/2002) ### Shopify: Run the platform checks a binding change affects Checkout Kit replaced its single protocol signal with language-specific binding signals and a shared-input signal. A Kotlin-only binding change now starts the Android consumers, and a schema or generator change still starts every platform. Evidence: Source PR/commit evidence Merged 2026-08-03; the per-binding signals are on the default branch. ([Source](https://github.com/Shopify/checkout-kit/pull/546)) Use it when: A monorepo starts every platform job for changes confined to one generated binding. Before applying it: Shared schemas, generators and lockfiles reach several languages, so they map to every consumer. [Read more in the Shopify playbook](https://starsling.dev/ci-playbooks/shopify#filter-platform-consumers) [Primary source](https://github.com/Shopify/checkout-kit/pull/546) ### Shopify: Skip platform jobs for documentation-only changes Checkout Kit keeps one shared filter file with per-platform filters that exclude Markdown files and docs directories, so a docs-only pull request starts none of the platform suites while workflow and filter changes still trigger validation. The same exclusions now live in .ci/changed-file-filters.yml on the default branch. Shopify CLI tried the workflow-level form and restored the tests, because they are required to merge. Evidence: Source PR/commit evidence Merged 2026-06-26; the exclusions are on the default branch. ([Source](https://github.com/Shopify/checkout-kit/pull/349)) Use it when: Documentation edits start expensive platform suites that build and test only source code. Before applying it: A workflow skipped at the trigger never reports its required checks; filter at the job level so the checks still report. [Read more in the Shopify playbook](https://starsling.dev/ci-playbooks/shopify#skip-docs-only) [Primary source](https://github.com/Shopify/checkout-kit/pull/349) ### Stripe: Gate expensive checks on their real inputs Stripe iOS decides whether SDK or build inputs changed before installing tools and running API or dead-code analysis; build configuration counts as an input even inside example or test directories. Sorbet runs its editor-extension jobs on branches only when the extension changed, and always on master. Stripe React Native skipped its end-to-end workflow for Markdown-only pull requests. Evidence: Source PR/commit evidence Use it when: Documentation or unrelated changes trigger an expensive, narrowly scoped check. Before applying it: A whole-workflow path filter can leave a required check pending. An always-present gate that reports a no-work result keeps branch protection intact; include global build inputs in the scope. [Read more in the Stripe playbook](https://starsling.dev/ci-playbooks/stripe#skip-unrelated-checks) [Primary source](https://github.com/stripe/stripe-ios/pull/7336) ## CI optimization is continuous work. Apply this technique yourself, or use StarSling Runners for faster GitHub Actions and optional agent-driven optimization PRs, which teams on eligible paid plans can turn on. [Get self-improving CI](https://starsling.dev/products/runners) ## Related techniques ### [Install and build only the workspace packages a job uses](https://starsling.dev/ci-playbooks/techniques/scope-workspace-builds) Scope dependency installation and builds to the package or lane under test, including its actual dependencies. 3 implementations · 3 companies (Linear, Mastra, Shopify) ### [Package once, and build full installers after merge](https://starsling.dev/ci-playbooks/techniques/package-once) Drop the build step that packaging repeats, and build the unpacked app pull requests test. 1 implementation · 1 company (DoorDash) ### [Reduce the setup floor before increasing shard count](https://starsling.dev/ci-playbooks/techniques/setup-cost-limits-sharding) Each extra shard repeats checkout, dependencies and container setup. 1 implementation · 1 company (Linear) ## Company Playbooks ### [Anthropic](https://starsling.dev/ci-playbooks/anthropic) Run only affected tests ### [DoorDash](https://starsling.dev/ci-playbooks/doordash) Run build and test in parallel, sharded across CI agents ### [Linear](https://starsling.dev/ci-playbooks/linear) Benchmark the same job on faster hardware ### [Mastra](https://starsling.dev/ci-playbooks/mastra) StarSling runners for the slowest test workflow ### [OpenAI](https://starsling.dev/ci-playbooks/openai) Rank CI fixes by the minutes they save ### [Ramp](https://starsling.dev/ci-playbooks/ramp) Move a CPU-bound test suite to a faster CPU ### [Shopify](https://starsling.dev/ci-playbooks/shopify) Let an agent iterate against one CI metric ### [Spotify](https://starsling.dev/ci-playbooks/spotify) Build arm64 on native arm64 runners ### [Stripe](https://starsling.dev/ci-playbooks/stripe) Run only the tests a change can reach ### [Uber](https://starsling.dev/ci-playbooks/uber) Build the merge-queue speculations most likely to be needed ## Related guides Implementation guides for this technique. ### [Cancel superseded CI runs](https://starsling.dev/best-practices/github-actions/cancel-superseded-runs) Use concurrency groups to keep PR verification focused on the latest commit. ### [Build and test only what changed](https://starsling.dev/best-practices/github-actions/build-only-affected) Scope work with your dependency graph and keep a full-run fallback. ### [Filter workflows by changed files](https://starsling.dev/best-practices/github-actions/path-filter-workflows) Use paths and job conditions while keeping required checks reporting. ### [Cut CI queue time](https://starsling.dev/best-practices/github-actions/cut-queue-time) Measure waiting time and identify concurrency or capacity constraints.