scripts/test.sh runs every batch sequentially inside one GitHub Actions job, so CI wall-clock is the sum of all test time. Measured 2026-08-15:
|
|
| serial phase |
~55 min (06:47→07:42 on run 31870162095) |
| three individual batches |
14–15 min each |
| parallel phase |
runs LAST, so it is what gets cut |
| a run with no test additions (PR #568) |
55m07s |
Two PRs were cancelled at exactly 1h00m and surfaced as red X's when nothing had failed — #571 twice. PR #572 raises the cap to 120 minutes as a stop-gap so work can land, but that treats the symptom: the suite will keep growing, and the next person to add a batch's worth of tests hits it again.
The durable fix
Split the batches across parallel jobs (an Actions matrix), so wall-clock tracks the longest batch rather than the sum. The batches are already enumerated in scripts/test.sh, so the matrix axis largely exists:
Worth doing together with #570 (the coverage audit), since both concern scripts/test.sh's batch structure: #570 asks which files are covered, this asks how the covered files are scheduled. A matrix built from a single declarative list of batches would answer both — each batch becomes a job, and any file matching no batch fails the audit.
Why it matters beyond speed
A cancelled job reports as a failure indistinguishable from a real one. #571's first timeout cost a full diagnostic round hunting a test failure that did not exist, and the parallel phase being last means the tests most likely to be truncated are the parallel-correctness ones — exactly the class where today's defects (#564, #560) were found.
Underworld development team with AI support from Claude Code
scripts/test.shruns every batch sequentially inside one GitHub Actions job, so CI wall-clock is the sum of all test time. Measured 2026-08-15:Two PRs were cancelled at exactly 1h00m and surfaced as red X's when nothing had failed — #571 twice. PR #572 raises the cap to 120 minutes as a stop-gap so work can land, but that treats the symptom: the suite will keep growing, and the next person to add a batch's worth of tests hits it again.
The durable fix
Split the batches across parallel jobs (an Actions matrix), so wall-clock tracks the longest batch rather than the sum. The batches are already enumerated in
scripts/test.sh, so the matrix axis largely exists:mpirun) phase as its own job, so it can never again be the thing that gets truncated;tests/analytic_full/, added in The analytic solution suite: uw.analytic with the full Velic family, an oracle-free validation contract, and four fixed defects #571) as an opt-in job that need not run on every PR.Worth doing together with #570 (the coverage audit), since both concern
scripts/test.sh's batch structure: #570 asks which files are covered, this asks how the covered files are scheduled. A matrix built from a single declarative list of batches would answer both — each batch becomes a job, and any file matching no batch fails the audit.Why it matters beyond speed
A cancelled job reports as a failure indistinguishable from a real one. #571's first timeout cost a full diagnostic round hunting a test failure that did not exist, and the parallel phase being last means the tests most likely to be truncated are the parallel-correctness ones — exactly the class where today's defects (#564, #560) were found.
Underworld development team with AI support from Claude Code