build-speed — measure, then change one thing, then measure the same way

A build is made faster by finding where the minutes go. Guessing goes to the step that looks heavy; measuring goes to the step that is. On this repository's own gate one step, lib tests run in a single worker, was 21–30 of 28–38 measured minutes: 75–80% of the gate. Eight workers took that step to 5 minutes; no cache would have.

1. Measure before anything changes

• Per step, not in total. The duration of each step from the CI log or the runner's API (gh run view --json jobs, the TAP duration_ms, timestamps around each step). A total says the build is slow; steps say where.
• At least three runs of unchanged code. Write down the range, not one number: a shared runner and a busy laptop both vary by a third.
• Note the conditions. Runner type, cores, cache state (cold or warm), concurrency flags. A measurement without its conditions cannot be repeated.

2. Pick one step and a target

The slowest step, unless a faster one runs on every commit and the slow one does not. Write the target before the change: "lib tests from 21–30 min to under 10 min, same tests, same pass count". No target, no way to say the change worked.

3. Change one thing

Usual levers, in the order they usually pay:

Parallel workers expose tests that share state: a database, a port, a temp path, a global config. A test that fails only in parallel is a real finding: give each worker its own resource. Never answer it by going back to one worker silently.

4. Re-measure the same way

Same method, same conditions, same number of runs. Report before, after, and the pass count of both. If the pass count differs, the change is not a speed-up: it dropped or broke tests.

Forbidden

Speed bought by checking less is not speed. Never:

• skip, delete, .only or mark as allow-failure a test or a step;
• lower a threshold, a coverage floor or a timeout so a check passes sooner;
• move a check out of the path to merge or deploy ("run e2e nightly instead") without the operator's decision, written down with its risk;
• run fewer tests "because they never fail".

Report

BUILD-SPEED <pipeline> @ <commit>
  step     : lib tests
  before   : 22–29 min (2 runs, 1 worker, 10-core host, CPU 80% idle)
  after    : 4.5–5.3 min (3 runs, 8 workers, same host)
  tests    : 4034 before, 4034 after, same pass count
  change   : ci-local.sh --jobs=8, lib tests only; root and board fixtures keep 2

A line you could not measure is NOT MEASURED with the reason.