Skip to content

ci: regenerate the shard-timings dataset on a timer, and assemble a sliced package per run #2

ci: regenerate the shard-timings dataset on a timer, and assemble a sliced package per run

ci: regenerate the shard-timings dataset on a timer, and assemble a sliced package per run #2

Triggered via pull request September 7, 2026 04:48
Status Failure
Total duration 1m 15s
Artifacts

shard-timings-refresh.yml

on: pull_request
Regenerate the shard-timings dataset
1m 11s
Regenerate the shard-timings dataset
Fit to window
Zoom out
Zoom in

Annotations

2 errors
Regenerate the shard-timings dataset
Process completed with exit code 1.
Regenerate the shard-timings dataset
The 7 eligible run(s) on main, accumulated together, still do not measure every package the committed dataset holds — the shortfall above names what is missing. A package can stay unmeasured across every retained run: turbo's cache key is namespaced per shard and only main pushes write it, so a package whose inputs have not changed is a HIT in all of them, and the generator refuses hits rather than recording a replay as a duration. NOTHING was regenerated and no PR was opened — this is a refusal, not a quiet success. If this is the steady state rather than a quiet week, the dataset needs a merge rule (keep the last measured weight for a package this refresh did not measure) rather than a wider run window; that is a decision, not a tuning knob, and it is tracked on the card.