Commit Graph
2 Commits
Author SHA1 Message Date
ehoandClaude Opus 4.8 2820cd3476 fix(ci): e2e — let Playwright manage both servers (fixes the 2-hour hang)
CI / e2e (push) Successful in 2m50s
CI / frontend (push) Successful in 1m49s
CI / storybook-a11y (push) Successful in 4m55s
CI / backend (push) Successful in 1m18s
CI / codeql (csharp) (push) Failing after 2m3s
CI / codeql (javascript-typescript) (push) Failing after 1m29s
CI / api-client-drift (push) Successful in 1m42s
The e2e job backgrounded `dotnet run &` and `ng serve &` in separate Actions
steps, then `npx wait-on` (no timeout) in a later step. A process started with
`&` in one step is killed when that step's shell exits, so wait-on waited forever
on servers that were already gone — the job hung until the runner's hard limit
(~2h; Gitea's act_runner doesn't reliably enforce timeout-minutes).

Move both servers into Playwright's `webServer` (an array: backend + `npm start`),
so Playwright starts them, waits for readiness, runs the suite, and tears them
down in the one `npm run e2e` process — CI and local alike. The CI e2e job is now
just npm ci / playwright install / npm run e2e. `reuseExistingServer` is on locally
(reuses a running app, incl. the docker stack) and off in CI (fresh start).

Verified locally via `CI=1 npm run e2e` against free ports + a clean db: both
smoke tests pass in ~15s (no hang). The earlier local failure was leftover SQLite
state (WP-22) from a dirty run resuming a Concept — CI checks out fresh, so its db
is always empty.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-21 20:07:35 +02:00
ehoandClaude Sonnet 5 26c2c5acd0 feat(fp): WP-19 — Playwright e2e smoke against the real FE+backend
Adds a happy-path spec (login → dashboard → registratie wizard, including
a real identity-document upload → real submit) and a degraded-path spec
(?scenario=error → <app-async> error slot → retry), both driving the real
app against the real .NET backend, plus a CI job that boots both.

Writing the retry spec surfaced a real bug: AsyncComponent's retry() only
reloads a [resource]-fed instance, so every real page (all [data]-fed via
a store's RemoteData) had a silently no-op retry button. Added a
retryClicked output and wired it on the dashboard's two async blocks.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-04 10:13:40 +02:00