Repository navigation
ci: refresh the shared shard durations from Ubuntu and macOS logs - #8465
Conversation
macos 3/4 hit its 20-minute limit in dev batch 42721779341 because the shared table was read from Ubuntu logs only. Refresh it from the passing test N/5 and macos N/4 jobs of run 42694893702, as the durations tool prescribes, and pin the new table in the release evidence policy.
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
✅ Deterministic PR hygiene checks passed. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
|
Post-merge integration record (maintainer, dev integration under the PR-only bypass in MAINTAINERS.md). This PR was squash-merged as Independent review of the exact head Corrections to the description, from that review:
Proof on dev: |
Summary
macos 3/4in dev batch 42721779341 (8cab704) was cancelled at its 20-minute job limit in batch 63/72, with no failing test. The same shard took 19.5 minutes in batch 42694893702. Linux and macOS shards sharescripts/ci/test-durations.tsv, and the current table was read from Ubuntu logs only, so files that cost much more on macOS land wherever the Linux weights put them. The planner predicted 794 s (13.2 min) per macOS shard; shards 1, 2 and 4 used about 15 to 16 minutes of tests, and shard 3 needed more than 18. The largest gaps arecodex-integration/codex-cli-update-apply(177 s on macOS, 2.2 times its row), andcodex-cli-update-process-fixtureandclients/link-ocx-child-e2e, which take 20 to 30 s on macOS and almost nothing on Linux.This refreshes the shared table as
scripts/ci/test-durations.tsprescribes, from the passingtest 1-5/5andmacos 1-4/4jobs of onelane=allrun (42694893702 on 4b38e9a, all nine jobs green): 3022 rows, all measured. A file measured on both platforms records the mean of its samples. The table is a pinned release-evidence input, so this also appends aciv1 entry to.github/scripts/release-evidence-policy.json, identical to the latest one exceptscripts/ci/test-durations.tsv(6ff82545…), keeping earlier entries (same procedure as #8463). The planner, shard counts and job limits are unchanged.Verification
run-bun-test-batches.shassigns), costed with the per-file macOS times measured in batch 42721779341 (falling back to 42694893702): the current table plans macOS shards at 15.6 / 15.3 / 19.2 / 15.8 min of tests, so shard 3 leaves no room for setup under the 20-minute limit; the refreshed table plans 16.8 / 16.1 / 16.4 / 16.6 min. Linux shards, costed with their own measured times: 7.7 / 6.6 / 7.6 / 6.9 / 7.7 min before and 6.3 / 7.8 / 7.5 / 7.4 / 7.5 min after.node .github/scripts/release-evidence.cjs policy-check: fingerprints match.node --test .github/scripts/release-evidence.test.cjs: 25 pass, 0 fail.bun testover the eighttests/ci-workflows/files that read the duration tables or the policy (ci-shard-balance, ci-test-lane, ci-workflows, ci-scope-reduction, ci-crash-disposition, release-preflight, release-pipeline-contract, release-resume-identity), isolated HOME: 295 pass, 0 fail.lane=allbatch is the proof; the plan leaves about 3 minutes of headroom per macOS shard after setup.Checklist
Summary by CodeRabbit