Playwright's webServer config tried to spin up its own server in CI
('reuseExistingServer: !process.env.CI' = false), but the workflow
already started one manually — port 3000 was busy and Playwright
errored before any test ran. Set reuseExistingServer: true always:
Playwright reuses whatever's responsive and only runs the command
when nothing is.
Forgejo doesn't support actions/upload-artifact@v4 (GHES-not-supported
error). Downgrade to @v3.
The Forgejo runner is itself a container (visible in 'docker ps' from
inside the job: GITEA-ACTIONS-TASK-N_WORKFLOW-Test_JOB-playwright).
'--network host' for Mongo binds to the outer Docker host's network
namespace, which the runner container can't see — that's why
mongodb://localhost:27017 from the Nuxt server returned ECONNREFUSED.
Drop --network host. Instead, after starting Mongo, look up the
runner container's own network via 'docker inspect $HOSTNAME' and
attach Mongo to it. MONGODB_URI now references the container by
name (mongodb://mongo-ci:27017/...).
The Forgejo runner image doesn't ship netcat — 30 retries of
'sh: 1: nc: not found' just burned the timeout. Use mongosh from
inside the container; no host-side tooling needed.
Previous run's container persisted across CI runs (runner shares the
host Docker daemon), so 'docker run --name mongo-ci' hit a name
conflict. 'docker rm -f mongo-ci || true' at the start of the step
makes it idempotent.
Wait-for-Mongo timed out at 30s after Start-MongoDB succeeded — typical
Docker-in-Docker symptom where -p port mapping binds to a network the
runner's node process can't see. --network host puts Mongo in the
runner's network namespace so localhost:27017 reaches it.
Also dump 'docker ps' after start and 'docker logs mongo-ci' on failure
so the next-step debugging isn't blind.
The Forgejo runner isn't honoring the 'services:' block — the playwright
job booted the server cleanly but every Mongo query returned ECONNREFUSED
on 127.0.0.1:27017. Replace 'services:' with an explicit 'docker run -d'
step + nc-based readiness wait.
server/utils/oidc-provider.ts throws at module-load when
OIDC_COOKIE_SECRET is unset and NODE_ENV is 'production'. Vite
substitutes process.env.NODE_ENV as a literal at build time, so
'production' is baked into the .output bundle regardless of the
runtime NODE_ENV=development env. Setting OIDC_COOKIE_SECRET
clears the throw; the value isn't used for real OIDC traffic
in CI since no test exercises the OIDC interaction routes.
Backgrounding 'node .output/server/index.mjs &' swallowed startup
crashes — failures presented as a useless 30s 'Wait for server'
timeout. Pipe stderr to a log file and cat it on failure so the
next crash is one click away.
server/plugins/validate-env.js process.exit(1)s on boot when these
are missing — the playwright job's 'Start server' step backgrounds
the process and returns instantly, so the crash was silent until
'Wait for server' timed out at 30s.
Stub values are safe: ALLOW_DEV_TEST_ENDPOINTS=true short-circuits
the Resend call in invite.post.js, and Helcim API calls are mocked
at the page.route level in join-flow.spec.js.
Without this flag, server/middleware/03.rate-limit.js applies the
100-req/60s general limit to /api/dev/test-login and trips during
parallel e2e runs. The invite.post.js dev short-circuit also
depends on this env var to skip the Resend call (no RESEND_API_KEY
in CI).
