chore(ci): refresh the Test Core shard-timings dataset - #20388
github-actions[bot] wants to merge 1 commit into
Conversation
Regenerated by .github/workflows/shard-timings-refresh.yml from the test-core-run-summary artifacts of 1 accumulated run(s) (36380128221), newest 36380128221 at eee0974. Generated, never hand-edited.
|
Claim: PM loop round 1 Why a seat claims a bot PR. The maintainer approved this PR and armed auto-merge on it (2026-09-30T05:51Z, How it lands. The dev opens a separate draft PR from the branch above that re-derives the pins so the self-test passes on both datasets: the one on Stamp: 2026-10-02T22:01Z · read against Generated by Claude Code |
|
os-dev-report Generated by Claude Code |
|
os-dev-report Generated by Claude Code |
ACCEPT — PR #21487 (head
|
Refreshes
scripts/test-shard-timings.json, the balancing input for the Test Coreshard split. Opened automatically by
.github/workflows/shard-timings-refresh.yml.Every byte came out of
scripts/measure-test-shard-timings.mjs; nothing here washand-edited, and no bound, timeout or matrix entry was touched.
Source
Measured across 1 accumulated run(s) of the HOURLY
schedulerun of CI onmain— the full-battery run (#16467). Apushrun onmainis affected-only andis not a measurement of the workspace, so no push run feeds this file.
No single green run measures the whole workspace either — turbo's cache is namespaced
per shard and only main pushes write it, so a
package whose inputs have not changed is a HIT and the generator refuses hits rather
than recording a replay as a duration. Runs are therefore accumulated, each fenced by
its own
--rungroup, until every package the committed dataset holds is measuredagain; a package seen in several of them gets the median of those observations.
https://github.com/objectstack-ai/objectstack/actions/runs/36380128221
Newest run in the set:
36380128221, commiteee0974236c87a7232f9805a19b6e53e3e36da59— the date this refresh carries.Every run above had all six
Test Core (N/6)jobs concludesuccesswith its sixrun-summary artifacts still retained; runs that were cancelled, failed or had lost
their artifacts were rejected by name in the log before any of these were used.
All 72 package weights were measured in these runs; nothing was carried.
because a weekly lane cannot know which cards a given run ought to retire. If this is
the first refresh to land, retire those two by hand as part of merging it.
Measured per-shard suite time on the newest run in the set
Predicted bins, before and after
The partitioner's own pins RED on this refresh — read this before merging
This is the designed behaviour, not a defect in the refresh: the acceptance bound is
a ratio, and a package that has grown past what any six-way split can bin makes the
pins fail with the arithmetic in the message. The remedy the partitioner names is to
raise the file-level slice count for that package — ⛔ never to raise the bound, and
⛔ never to hand-edit this dataset. This workflow deliberately does neither: it
reports and stops, because both are decisions.
No checks will start on this PR by themselves
It was opened with the Actions
GITHUB_TOKEN, and GitHub's recursion guard means aPR opened that way triggers no workflow runs. Push any commit to the branch, or close
and reopen the PR, to start CI.
Refs #16464, #16173, #16222.