Chapter 2 · Practice 1 of 4
Keep the main pipeline to a few minutes
Why it matters
DORA's trunk-based guidance says the build and test process should run in a few minutes. When it takes much longer, people stop waiting for it, start new work in parallel and batch changes, and failures are discovered long after the context is gone.
Where the time usually goes, and what to do about it:
| Cause | Fix |
|---|---|
| Downloading dependencies on every run | Cache them, keyed on the lockfile |
| Everything runs in one job | Split into parallel jobs |
| Slow end-to-end suites on every commit | Run a fast subset on pull requests, the full suite on main or nightly |
| Rebuilding unchanged parts of a monorepo | Build and test only what changed |
Put the cheapest, most likely to fail checks first (lint, type check, unit tests), so a typo fails in seconds, not after a ten-minute integration run.
To check, track the median and slowest pipeline duration over time. Set an alert or a budget, and treat a slow pipeline as a bug.
Example
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<full-commit-sha>
- uses: actions/setup-node@<full-commit-sha>
with:
node-version: 24
cache: npm
- run: npm ci
- run: npm run lint && npm run typecheck
- run: npm test