Skip to content

ci: run Node and Cloudflare E2E as separate jobs and report every failing shard - #4329

Open
danielmlr wants to merge 1 commit into
daniel/ci-e2e-build-oncefrom
daniel/ci-e2e-split-targets
Open

danielmlr wants to merge 1 commit into
daniel/ci-e2e-build-oncefrom
daniel/ci-e2e-split-targets

Conversation

@danielmlr

Copy link
Copy Markdown
Contributor

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-node and test-e2e-cloudflare now 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.

main runs CI one at a time, with one waiting slot. From 2026-10-17 to 10-20, 25 of 70 CI runs on main were replaced by a newer push before any job started. Shorter runs mean more main commits get tested.

Builds on #4317 and targets its branch until it merges, so the diff shows only this change.

Type of change

  • Bug fix
  • Feature (requires an accepted feature plan or RFC)
  • Refactor (no behavior change)
  • Translation
  • Documentation
  • Performance improvement
  • Tests
  • Chore (dependencies, CI, tooling)

Your connection to this change

  • I use EmDash and ran into the problem this PR addresses
  • I maintain a tool, dependency, or service that EmDash uses, and this change concerns that integration
  • A Maintainer approved this specific change before I opened the PR

Checklist

  • I have read CONTRIBUTING.md
  • pnpm typecheck passes
  • pnpm lint passes
  • pnpm test passes (or targeted tests for my change)
  • pnpm format has been run
  • I have added/updated tests for my changes (if applicable) (n/a: workflow change; the CI run below exercises it)
  • User-visible strings in the admin UI are wrapped for translation (if applicable). Do not include messages.po changes except in translation PRs — a workflow extracts catalogs on merge to main. (n/a: no admin UI change)
  • I have added and reviewed the user-facing changeset (if this PR changes a published package) (n/a: CI workflow only)
  • New features link to their merged design PR: https://github.com/emdash-cms/emdash/pull/... (n/a: not a feature)
  • I have included screenshots below if this PR changes the UI (n/a: no UI change)

AI assistance disclosure

  • This PR includes AI-generated code or text — model/tool: Claude Opus 5.5

Screenshots / test output

Test output:

  • Before: in the last five successful main runs 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.
  • After, on a fork with the same runner type, two full CI runs of this branch on top of ci: build the E2E fixtures once instead of two or three times per job #4317 (run) against two of 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:
    • Node E2E jobs took a median 6 min 1 s and 7 min 12 s, Cloudflare E2E jobs 7 min 12 s and 8 min 32 s. The slowest E2E job took 12 min 1 s and 11 min 43 s.
    • The whole run took 13.0 and 12.0 min, against 15.7 and 21.1 min for main on the fork and 18.2 to 21.9 min for the five upstream main runs above. Browser Tests, at 11 to 13 min, is now about as slow as the slowest Cloudflare shard.
    • E2E runner time stayed about the same: 109 and 120 min, against 97 and 118 min on main.
  • Typecheck, lint and every test job passed in both runs.
  • zizmor 1.26.1 with .github/zizmor.yml: no findings in the default persona, and the same counts as main in the pedantic and auditor personas.

…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.
@changeset-bot

changeset-bot Bot commented Oct 21, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 8842da7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@emdashbot emdashbot Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant