COMPOSE_PROJECT_NAME was "ruvdstests" but the live stack was actually
deployed under "ruvdstest" (no trailing s) — Compose treated it as an
unrelated project and spun up a whole second stack from scratch,
colliding with the real one's host port and aborting mid-deploy
instead of updating the running containers in place.
The job checks out into the runner's own workspace, not
/opt/ruvdstests where DEPLOY.md has the human create a .env file — so
docker compose here had no .env to read JWT_SECRET from and failed
outright. POSTGRES_PASSWORD would have silently fallen back to the
compose file's devpassword default instead of erroring, which on
Deploy would have broken auth against the already-initialized pgdata
volume.
Host-mode jobs execute directly on the bare runner container rather
than a per-job container, and actions/checkout is a JS action — it
needs `node` on PATH to run at all, which the runner image doesn't
ship. Failed every run with "Cannot find: node in PATH" before any
other step got a chance to install anything.
On every push/PR: run Domain.Tests, then docker compose build to validate
the full stack still builds. On push to master: also docker compose up -d
to redeploy. COMPOSE_PROJECT_NAME is pinned to ruvdstests so a run from a
runner-managed checkout always targets the existing stack/volumes instead
of spinning up a duplicate under a different project name.
