Repository navigation
Conversation
…ling shard Each E2E shard ran the Node target and then the Cloudflare target, so the slowest shard paid for both and set the run's wall clock. #3277 paired them to cut the job count while the org could run only 20 jobs at a time, and that limit no longer applies. Run test-e2e-node and test-e2e-cloudflare as separate 8-shard matrices, each gated on its own plan output and building only its own fixture, and have the Tests job check both. Set fail-fast: false on the vitest and E2E matrices again, so a red run shows every failing shard and 'Re-run failed jobs' repeats only those instead of every shard that fail-fast cancelled.
|
There was a problem hiding this comment.
Splitting the Node and Cloudflare E2E targets into independent jobs is a sound way to stop every shard from running both targets in series. Disabling fail-fast also fits the goal, since "Re-run failed jobs" now re-runs only the shards that failed. Both reviewers approved and found no actionable issues.
The reviewers checked the gating of each job on its test-plan.mjs output and the needs list and check_lane handling in the Tests aggregate. They also checked the per-target fixture builds, the artifact naming and upload condition, and the retained E2E Tests and Tests job names. One caveat remains: it could not be confirmed statically that no branch ruleset still requires the old E2E shard (n/8) check names. CI execution and the reported timing improvements were not verified. No changeset is needed, because only the CI workflow changes.
Reviewed by anthropic/claude-opus-5-5 and openai/gpt-6.1-sol.
What does this PR do?
Runs Node and Cloudflare E2E as separate jobs. Together with #4317, this brings a full CI run from about 20 minutes down to 12 or 13. A red run now shows every failing shard.
Each E2E shard ran the Node tests and then the Cloudflare tests, so the slowest shard paid for both. #3277 paired them to cut the job count while the org could run only 20 jobs at a time. That limit is gone.
test-e2e-nodeandtest-e2e-cloudflarenow run 8 shards each. Each starts only when the test plan selects its target and builds only its own fixture. Each gets a 25-minute timeout instead of 40, about twice the slowest run measured. The Tests job checks both, and required check names don't change.The core unit test shards and both E2E jobs go back to
fail-fast: false. With fail-fast, "Re-run failed jobs" also re-ran every shard that fail-fast had cancelled. In run 39123937452, one flaky shard failed and all 8 ran again. The cost is that a failing run turns red only when its slowest shard finishes, not as soon as the first one fails. That run went red 51 seconds after its failure. Without fail-fast, it would have waited for the other shards, and the split makes them shorter.mainruns CI one at a time, with one waiting slot. From 2026-10-17 to 10-20, 25 of 70 CI runs onmainwere replaced by a newer push before any job started. Shorter runs mean moremaincommits get tested.Builds on #4317 and targets its branch until it merges, so the diff shows only this change.
Type of change
Your connection to this change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges except in translation PRs — a workflow extracts catalogs on merge tomain. (n/a: no admin UI change)AI assistance disclosure
Screenshots / test output
Test output:
mainruns up to 8da0792 (2026-10-20), an E2E shard took 13 min 23 s (median, longest 21 min 30 s), with Node E2E at 5 min 7 s and Cloudflare E2E at 5 min 23 s one after the other.main(run). The fork runs only 20 jobs at a time, so these add up job times (Test Plan, the slowest job, Tests) instead of reading the run's clock:mainon the fork and 18.2 to 21.9 min for the five upstreammainruns above. Browser Tests, at 11 to 13 min, is now about as slow as the slowest Cloudflare shard.main..github/zizmor.yml: no findings in the default persona, and the same counts asmainin the pedantic and auditor personas.