CI: server-hosting-type E2E (in-runner, no cloud) + cypress wizard
Follow-up from #5453 / #5429. Add an E2E for the self-hosted server hosting type, mirroring the AWS /e2e flow (.github/workflows/pullRequestsCommandE2e.yml) but running entirely in the GitHub runner.
Why it's simpler than the AWS E2E
Server flavour = SQLite + single Node process. No cloud → no AWS creds, no Pulumi backend, no OpenSearch secrets, no per-storage matrix, no teardown. Everything runs in ubuntu-latest.
Shape
- Reuse the existing scaffold half: publish packages to Verdaccio →
create-webiny-project ... --template-options '{"hostingType":"server"}'(the new CWP prompt → server/sqlite). - Instead of
webiny deploy→ run the server in-runner. Prefer building the deploy ARTIFACT and running it (validates #5453):webiny-server build→ runbuild/start.mjs(api) in the background + serve the admin build;wait-onthe api. (Alternativelywebiny-server servetests the dev/serve path.) - Cypress
adminInstallationwizard againstlocalhost— same spec as AWS.
Placement
Likely a SEPARATE workflow (serverE2e.wac.ts) rather than a leg in the AWS matrix — shares the scaffold pattern but none of the AWS job env/Pulumi. Or add a "Server" row to the /e2e PR-comment table.
Nice-to-have
Once the server WebSockets runtime issue is fixed, a cypress assertion on a live notification (upload image → AI tags appear without reload) would exercise bg-tasks + scheduler + WS together — a strong server-specific check.
Notes
- Test secrets baked as build params are fine here (throwaway project).
- Build in the Linux runner → native binaries (sharp, better-sqlite3) match by construction.
Related: #5453, #5429.
Source: webiny/webiny-js