I’m redesigning a CI pipeline with checks like linting, type checks, tests, manifest validation, builds, and security scans. Should it stop as soon as something fails, or keep running independent checks so one run can show a fuller set of problems?
Should CI stop at the first failure or show every failure?
Asked by
trombone+practice
Answers
I’d make the pipeline fail fast only where later work depends on an earlier result. There’s little value running a test stage that needs an artifact the build never produced.
For independent, quick checks, parallel execution can give developers more useful feedback in one run. That costs more runner time, so the right split depends on how often checks fail, how long they take, and how busy or expensive your CI capacity is.
Reply to this answer
For a small team, I’d usually run the fast, independent checks together. If linting, type checking, and manifest validation can finish quickly, seeing several results at once can save a round trip of edits and reruns.
That doesn’t mean every expensive stage has to run after a clear blocker. You can stop dependent work, or reserve costly end-to-end tests for changes that pass the basic gates.
Reply to this answer
My bias is toward resource efficiency when builds are frequent or CI capacity is tight. A cheap check near the start can catch obvious problems before a long build or test suite consumes runners.
Just don’t confuse “stop on failure” with making everything strictly sequential. Independent quick checks can still run together, while later stages wait for the artifacts or prerequisites they actually need.
trombone+practice:
Would you apply the same rule to security scans, or run those separately?
lunchbreak registrar:
That depends on the scan and its purpose. A scan tied to the built artifact belongs after that artifact exists, while other scans may be useful on a separate schedule as well as during changes.
Reply to this answer
One practical pattern is to group checks by what they need: source-only checks first, then build the artifact, then run checks that need that artifact. Run jobs within a group in parallel where it makes sense.
Also make sure the artifact tested downstream is the one you intend to deploy. Otherwise a green test result may not tell you much about the thing that actually ships.
Reply to this answer
There isn’t a universal winner here. If most runs pass, parallel independent checks can improve feedback time. If failures are common, stages are expensive, or runner capacity is scarce, early gating can avoid wasted work.
I’d look at actual pipeline duration, failure patterns, and CI usage, then adjust the stages that are costing the most. It’s fine for different checks to follow different rules.
Reply to this answer
Add your answer
Answers are reviewed before publication.
w7_inkwell:
So the key is dependency-aware stages, rather than choosing one policy for the whole pipeline?