Design CI so cost tracks the surface area actually touched, not the number of\npushes. Use this language wherever CI is being designed, reviewed, or audited.
\nFix in this order — each tier assumes the ones above it are already sound:
\nBaseline failure noise (a flaky test, a known-red job) matters less than any\nof these — it's visible and locally fixable. Structural waste isn't; it\ncompounds silently across every run.
\nUse these terms exactly.
\nTrigger surface — the product of events, branches, and paths that fire a\nworkflow (on: push/pull_request × branch filters × path filters). The\ntrigger surface is the first lever: a workflow that fires on every push to\nevery branch has a trigger surface many times larger than the work it\nactually needs to validate.
Path filtering — restricting a job to run only when files it cares about\nchanged. The required-checks-safe pattern: never put paths: at the\nworkflow level on a job that's a required status check — GitHub can leave a\nrequired check permanently pending if its workflow never triggers. Instead,\nfilter inside the job with a paths-filter step that gates the real work,\nso the workflow still runs and reports green (or explicitly skipped) on\nevery PR.
Concurrency group — a concurrency: key that cancels superseded runs on\nthe same branch/PR (cancel-in-progress: true), so a burst of pushes\ncollapses to one live run instead of a growing queue. Release and deploy\npaths are the deliberate exception: don't cancel a run that's mid-deploy\njust because a new commit landed.
Caching — persisting dependencies or toolchains across runs, keyed on\nsomething that changes only when the cache should invalidate (a lockfile\nhash, a pinned tool version). The sin isn't the absence of a cache line —\nit's reinstalling a toolchain, browser binary, or dependency tree from\nscratch on every single run when the inputs didn't change.
\nRunner cost tiers — macOS runners cost several times what Linux runners\ncost per minute; Windows sits in between. A job earns a pricier runner only\nby a real platform dependency (building a macOS binary, testing an\nXcode-only path) — never by inertia or a single assumption (like a temp\npath) that's trivially fixable on Linux.
\nScheduled scans — expensive or slow analysis (security scanning, full\nmatrix builds) that doesn't need to gate every PR. When merge velocity is\nhigh, put it on a schedule plus main-branch pushes instead of every pull\nrequest — it still runs regularly, just not once per push.
\nIteration burst — a string of pushes to the same branch in quick\nsuccession, each firing its own run. Expected during active development,\nnot itself a problem. The concurrency group is what determines whether a\nburst turns into cancellations (cheap, correct) or a queue of runs that\nfinish stale and red (expensive, misleading).
\nInvisible checks — status checks that show up on a PR with no\ncorresponding yml in the repo, most commonly GitHub's CodeQL default setup\nconfigured through repo settings rather than a workflow file. They can't be\ninventoried, diffed, or reviewed by reading the repo. Export them to a\nchecked-in workflow so every check the repo runs is visible from its files.
\n