docs(hr-benchmarking): total per-file test startup and read CI's own durations before tuning
Adds two paragraphs to hr-benchmarking about where a slow or timing-out test suite's time actually goes, with changelog entries.
Total the per-file startup first. In one suite of 754 test files, the startup each file paid summed to 205 s. Running without per-file isolation (--no-isolate) saved only 11 s and broke 12 files, so tuning individual slow files would have targeted the wrong cost.
Read CI's own passing-run durations before reproducing a CI timeout. In bompus/codegraph#537, two tests took 2.0 to 2.5 s and 2.8 to 11.6 s in passing Windows CI runs. On a desktop they took 1.5 s and 2.5 s. Twenty local runs, ten of them pinned to 4 cores with the affinity verified, gave 0 failures. The runner was honestly slow, not hung, and only its own durations showed it.
The skill text names no project or figures; the figures above are the evidence.
Checks: bun run check exit 0, bun test 597 tests, 0 failed (8 skipped). A local reviewer pass found one unclear reference ("that comparison"), now "those durations"; it found no contradiction with the Actions procedure's timeout guidance or the affinity notes in references/tools.md.
Summary by cubic
Adds two diagnostics to hr-benchmarking for slow test suites, with changelog entries.
- Before splitting or tuning slow files, total the startup time each test file pays; in one suite that startup summed to 205 s and
--no-isolatesaved only 11 s. - Before reproducing a CI timeout locally, read the per-test durations from CI's own passing runs, which can show honest runner slowness that a desktop won't reproduce even when limited to the runner's core count.
Summary by CodeRabbit
- Documentation
- Added guidance for investigating slow tests, including checking per-file startup costs and CI test durations before making changes or reproducing timeouts.
- Clarified when to raise platform test deadlines.