The test is a performance guard, added the same morning with the fix that stopped the canvas view from being rebuilt once per write. It timed each round with the wall clock. CI runs every test file in parallel on a runner with few cores, so the process also spends time waiting for a core. The code the test runs was the same in all three builds; only the load on the runner differed.
| Build on main | The test took | Result |
|---|---|---|
| 11:47 Board changes no longer rebuild the canvas view… | 737 ms | pass |
| 13:44 The watch for new code no longer holds up the server… | 799 ms | pass |
| 14:19 The watch for new code reads branch names as git does… | 1,628 ms | fail |
Verdict: flaky. No build failed on it before; the last failed builds before this one date from 22 October, and many green builds followed them.
The test now measures the CPU time the process actually computes in each round, not the clock. Waiting for a core no longer counts. The bound stays at half a second.
| Longest round, measured on a laptop | Clock (before) | CPU time (now) |
|---|---|---|
| Current code, idle machine | 71–78 ms | 124–131 ms |
| Current code, every core busy twice over | 168–337 ms | 155–186 ms |
| Current code, full test suite in parallel | — | 148 ms |
| Old code (view rebuilt per write), idle | 385–411 ms (passed!) | 633–639 ms |
| Old code, every core busy twice over | 973–1,068 ms | 686–710 ms |
CPU time hardly moves under load. As a bonus, the test now also catches the regression it guards against on a fast machine: with the clock, the old code passed there.
CI runners have slower cores than the laptop. By the durations in the CI logs, a round should count about 250–350 ms of CPU time there, which is still below 500 ms. The next build on main shows the real figure.