Skip to content

test(e2e): run the Node suite against an astro build --devOutput build - #6

Open
ostenbom wants to merge 4 commits into
mainfrom
e2e/dev-output-build
Open

ostenbom wants to merge 4 commits into
mainfrom
e2e/dev-output-build

Conversation

@ostenbom

@ostenbom ostenbom commented Oct 27, 2026 •

Copy link
Copy Markdown

What does this PR do?

Most of the Node E2E time goes to astro dev compiling pages on first request. This PR runs the Node shards against a built fixture instead, using astro build --devOutput. This is a simpler way of retaining existing methods of "dev only" functionality while providing a small speed boost.

It's opt-in: EMDASH_E2E_BUILD=production switches e2e/global-setup.ts to build and serve the fixture, and CI sets it only for the Node step. The Cloudflare step and the 8-shard layout are unchanged. The rest is what the fixture needs to work as a built site: manual i18n routing, a sharp dependency, the registry fixture installed from middleware, and an https: image URL in one test. There is also one small core fix. The build-time registry check rejected the suite's localhost mock marketplace for --devOutput builds, even though the built site accepts it at runtime.

Node E2E on CI (8 shards) Slowest shard Total across shards
astro dev (main) 7.1 min 35.4 min
astro build --devOutput (this PR) 5.5 min (−23%) 24.1 min (−32%)

A real production build is a lot faster (2.8 min), but it needs a new config option; that's #7. For a full local run you also need the test fixes in #10. I also tried this build on Endform, which runs the whole suite in one job against a single server (#8). Under that load the dev-output server times out, and the production build doesn't.

Honestly I think #7 is better - long term this will provide a more stable suite, if you accept the tradeoffs.

I used claude to help me create this PR, but I have run the suite and reviewed the code myself.

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): full Node E2E suite against the dev-output build (344 passed, 34 skipped)
  • pnpm format has been run
  • I have added/updated tests for my changes (if applicable)
  • User-visible strings in the admin UI are wrapped for translation (if applicable): not applicable, no admin UI change
  • I have added and reviewed the user-facing changeset (if this PR changes a published package)
  • New features link to their merged design PR: not applicable
  • I have included screenshots below if this PR changes the UI: not applicable

AI assistance disclosure

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

Screenshots / test output

Not applicable.

ostenbom and others added 3 commits October 27, 2026 13:45
EMDASH_E2E_BUILD=production now builds the Node fixture with
`astro build --devOutput` and serves dist/server/entry.mjs instead of
running `astro dev`. The build keeps `import.meta.env.DEV` true, so the
dev-bypass, dev-reset and captured-email endpoints the suite depends on
work without any test switch in EmDash.

Also fixes what a built fixture exposes: manual i18n routing so the
fixture's [locale] pages win over Astro's fallback routes, sharp for
the image endpoint, the registry fixture installed at server start, an
https image URL for the CSP, and an ignore rule for the migrations
journal that builds write into the fixture.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The build-time registry check only allowed localhost for `astro dev`
and `astro sync`, while the runtime check follows import.meta.env.DEV.
A --devOutput build therefore failed at build time although the built
site would accept the URL. Astro sets NODE_ENV=development for
--devOutput before loading the config, so the build check uses that.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant