Repository navigation
PR CI wall time: shard Lite tests by class-name hash, measure the PG job's ladder cost before prebuilding, and un-invert the whole-tree guards filter #3887
Description
Erik's assignment (via monitor health loop, 13:41Z): shorten PR CI wall time. Measured baseline from the loop's step-level data over 8 recent Build runs: PR wall = the build job at 10–15m; inside it Run Lite tests = 9m28s of 15m15s (62% of the critical path; 4,014 DuckDB-heavy tests); parallel jobs: Darling PG tests ~8m, Linux ~2m, guards 20s–5m; the docs fast path already works (18s on splice PRs).
Ranked work:
- Shard Lite tests 3-way by class-name hash modulo in a matrix. Explicitly NOT a semantic filter: the workflow's own Batch DuckDB test seeding: shared connection + one transaction per seed helper #1694 comment (build.yml:382) records why the semantic lite_analysis split was retired — filter drift. Hash-mod cannot drift and cannot lose classes (every class hashes somewhere; a census can prove the union). Expected: 9m28s → ~3.5m, PR wall 15m → ~8m. Known cost: setup+restore repeated per shard, ~90s each.
- Darling PG tests: prebuilt image with the migration ladder pre-applied, rebuilt only when Migrations/** changes (dorny filter machinery exists). Expected 8m → 4–5m. GATED ON MEASUREMENT: the one-unlanded-rung cadence means the image rebuilds often this month, so step timings must first show ladder-replay is actually the long pole inside that job — if it is not, record the measurement here and defer.
- Rule-11 fold-in candidate: whole-tree guards runs ~5m on changelog-splice PRs vs 20s on code PRs — an inverted filter branch somewhere in the same file.
Constraints (binding): build.yml sits in the root dorny filter, so the fixing PR itself runs the full matrix — the PR is its own test; do NOT restructure the dorny filters (the predicate-quantifier trap comment at build.yml:100–111 documents live history); the docs fast path stays untouched. Target: PR wall ~5–6m with zero test coverage lost.
Activity
erikdarlingdata commentedon Sep 22, 2026
Claimed at filing (pm-user-worker seat). Sequence: fresh step-timing measurement first (items 2 and 3 are measurement-gated), then the hash-mod shard + whatever the measurements license, one PR.
The horizon pin follows the gate that now runs the suite, not the ste…
The Lite suite runs as four hash-cut shards in parallel instead of ni…
erikdarlingdata commentedon Sep 22, 2026
Done in b1ca391 (PR #3888), and
Lite tests (result)is now in dev's required status checks (verified: build, Darling PostgreSQL tests, Lite tests (result)), so the shards gate merges.Measured on the PR's own final run: build 6m16s (was 15m15s), shards 3m45s/3m47s/3m54s/4m21s, result job 2s, Darling PG 7m3s, Linux 1m40s. PR wall ~15m → ~7m.
Item 1 shipped as four shards, not three, on measurement: the hash balances classes but Lite's classes carry uneven test counts, so a 3-way cut left one shard with 42% of the tests (~6.5m) against another's 25%; four levels it at 27%.
Item 2 (PG prebuilt image) stays DEFERRED on its measurement — no ladder-replay step exceeds 30s; the ~271s is test execution. Item 3 was not a bug: the whole-tree guards' splice-vs-code split is the designed complement, running the full Darling suite exactly when the build job's filters left it unrun.
NOT at the ~5–6m target, and the reason is a new finding rather than a shortfall in item 1: the critical path has MOVED to Darling PostgreSQL tests (7m3s), which now bounds the wall by itself. Since the measurement says that job's cost is its tests and not its ladder, the lever there is this same sharding treatment rather than the prebuilt image — filed as its own issue with these numbers.
The Darling PG suite runs as three hash-cut shards, and the check bra…