Repository navigation
chore(ci): refresh unit weights from verified hosted artifacts - #2143
Conversation
fc072b3 to
ccac1a0
Compare
|
2026-10-16 actual-squash measurement completes the remaining #2122 balance criterion. Main run 38914099262 attempt 1 has four successful unit jobs, each with a successful Complete unit proof step:
Slowest/fastest = 1330/1169 = 1.137725, below 1.25. Historical baseline 38886704020 has steps 840/1530/864/1013 s, ratio 1.821429. Step sum increases from 4247 to 4882 s while maximum decreases from 1530 to 1330 s. This is an observed balance improvement across explicitly different sources and discovered inventories, not a controlled same-SHA causal speedup or whole-CI saving. The baseline is All four actual checkout logs, proof-checkout and resource receipts identify squash Execution logs show Bun 1.4.2 ( Together with the delivered refresh validation, named unweighted-120-second and restored mutation receipts, original passing preflight/typecheck, unchanged partition coverage and equal current predicted loads, this satisfies the issue's scoped acceptance. PR #2143 and this issue retain milestone 0.44.0. The aggregate and other categories remain outside this bounded timing verdict; no complete whole-main green claim is made or awaited. No new implementation, refresh or test rerun occurred during this audit. |
Refs #2122
What changed
Unit shard weights now come from an explicit reviewed refresh of a named successful hosted CI run and attempt. The tool requires four fresh successful unit jobs, attempt-bound artifacts with matching downloaded ZIP digests, one actual checkout, immutable tree/parent identity, exhaustive source discovery, and exactly matching completed JUnit/timing/file partitions. It rejects partial or failed measurements. A 30-second missing-weight guard names expensive omissions; unknown newly discovered files still receive the positive default. Shard count, deadlines, partition algorithm and runtime offline guards are unchanged.
Why this shape
Follows the issue's approved measured-cost approach and the browser refresh precedent. Timings remain reviewed development inputs; ordinary CI never downloads measurement artifacts. Historical partial observations remain historical, while the new measurement record describes the complete current table. No package or public machine contract changes, so no changeset is needed.
Proof
Source base:
626a03af4a9db064751230a84732755b8afa961e. Committed implementation head:fc072b311.The actual refresh command
bun scripts/refresh-unit-costs.ts 38886704020 1succeeded twice against the named successful automatic main run. All 955 measured source files and all four downloaded archive SHA256 digests match immutable evidence. That source is5af94530672aec0999c571b3f8774a71f4f97729, tree5813c3f87dbd43bd5f771ac39b0206bc42a521dc, parentab0e9fb77a236cefbe5a0b19424836acf9205bde. The committed measurement record retains exact job/artifact identities and step durations.These are actual step times, distinct from the reported completed-file totals of approximately 838/1528/856/971 seconds. The refreshed long-file observations include artifact recovery 162.977 s, hygiene review 129.067 s and turn journal 91.782 s. Applying the guard to actual hosted timings with the original committed table fails first with
Missing unit weight above 30s: tests/pi-worker-runtime.test.ts; the complete refreshed table includes that omitted 74.883-second file as well.On this branch's current 960-file discovery, four predicted loads are 1056.785 / 1056.784 / 1056.785 / 1056.784 seconds (max/min 1.000001). These are estimates from historical observations, not measured runtime improvements or current-candidate proof. Source changes since the historical run are not represented as a controlled same-SHA benchmark.
bun run check:pr --base origin/mainpasses 864 tests / 5541 assertions, including lint/leakage and contribution gates.Current integration — 2026-10-16
The maintainer explicitly authorized merging after prior tests passed, with conflicts checked after merge, and requested no full refresh solely for base advancement. The branch now applies only its six-file scope on actual main
55dbf1cf5e92cc084d3fde99c6e5c409854f7465, retaining incoming #2073/#2072 product changes. Current head isccac1a0b10a425231d3678dcb57fa993efb4ea3b; tree is65bb76f5f3e49130fc05501ef0fbf2fddbb913c0. None of the six owned files changed in either incoming main commit. All six file contents are byte-for-byte identical to the original tested implementationfc072b3111f04d633d06785cefbcc6bf882a93af; the rebase has no source conflicts. Incoming product and SDK changes are preserved.The integrated refresh/partition runtime suite passes 34 tests / 70 assertions.
git diff --checkpasses. Current 968-file discovery assigns 241/241/243/243 files exactly once, with predicted loads 1056.985 / 1056.984 / 1056.985 / 1056.984 seconds. The original 864-test preflight, strict typecheck and restored mutation receipts retain their original source identities; they are not relabeled as full tests of this combined tree. No full candidate confirmation is claimed or required by this session's explicit maintainer instruction. The automatic postmerge run will provide actual integrated runtime measurements.Checklist
Anything left open
The actual next complete hosted run must meet the unit step max/min <1.25 criterion; historical weights and equal predicted loads do not establish that outcome. This independently useful refresh slice uses
Refs #2122, so the issue stays open for the actual postmerge measurement and full acceptance reconciliation. No whole-CI speedup is claimed. #2121 separately owns within-shard parallel execution and preserves this timing schema. This session's explicit maintainer instruction permits integration using retained passing proof and focused conflict checks instead of a full new candidate confirmation.