Fail Fast

~9 min · fail-fast, ordering, pipeline-design

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

Cheap checks before expensive ones

If lint takes 30 seconds and tests take 8 minutes, run lint first. If it fails, the tests don't run at all — you save 8 minutes per failed PR. The principle generalizes:

Format check (5 sec) — first.
Lint (30 sec) — second.
Type check (1–3 min) — third.
Unit tests (2–10 min) — fourth.
Integration / e2e tests (5–30 min) — fifth.
Performance budget / smoke deploys — last.

The job-level needs: graph encodes this. fail-fast at the matrix level encodes the same idea within a single job's parallelism.

Counter-pattern: parallelize for visibility

On main, you may want the opposite: run everything in parallel and report all failures at once. This is the 'tell me everything that's broken' mode for retrospective analysis. Most teams use fail-fast on PRs and full-parallel on main.

Code

Fail-fast pipeline shape·yaml

jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ruff format --check .

  lint:
    needs: format
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ruff check .

  type-check:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: mypy src --strict

  test:
    needs: type-check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pytest -q

External links

GitHub — Choosing what your workflow does

Exercise

Sketch your current CI as a DAG. Identify the cheapest check that's currently downstream of an expensive one. Move it upstream. Push and time the next failed PR — cycles saved.