Performance Tuning

~10 min · performance, speed, optimization

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

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

The 8 levers

To make CI faster, attack one or more of these in roughly priority order:

Parallelize jobs — independent work in parallel jobs collapses wall-clock.
Cache aggressively — install, build output, Docker layers, model weights.
Use larger runners — for CPU-bound steps, double the cores often halves the time. Linear cost, sub-linear time? Win.
Skip what doesn't apply — paths filters, conditional jobs.
Concurrency cancel-in-progress — kill stale runs.
Smaller test subsets on PR — smoke on PR, full on main.
Faster install tooling — uv vs pip, pnpm vs npm, cached docker buildx.
Test sharding — split slow suites across runners.

Measure, don't guess

Before optimizing, look at the run timeline. The longest step is your candidate. GitHub's run page shows per-step duration; gh run view --log gives you raw timings. Optimize the worst, re-measure, repeat.

Code

gh run timing — find the bottleneck·bash

# Most recent run id
run=$(gh run list -L 1 --json databaseId --jq '.[0].databaseId')

# Per-job duration
gh api repos/:owner/:repo/actions/runs/$run/jobs \
  --jq '.jobs[] | {name, started_at, completed_at}'

# Or: look at the run summary in the UI; per-step durations are shown.

External links

GitHub — Workflow run usage

Exercise

Pick your slowest workflow. Pull the timeline of the last 10 runs. Identify the single step that dominates p95. Apply one of the 8 levers to it. Re-measure after 5 more runs.