The runner shares the host's Docker daemon across every repo's CI jobs, so
a hardcoded host port (8080) is a shared resource, not scoped to this job —
that's what was actually colliding, not a leftover vu-smoke container (the
previous fix's cleanup didn't help because the conflicting container wasn't
named vu-smoke at all). Curl the container's own bridge IP instead, so
nothing is published to the host and there's nothing to contend over.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The shell runs with -e, so a failed curl/grep check on any past run would
skip docker stop and leave vu-smoke bound to port 8080 — which is exactly
what happened, blocking this run's own docker run with "port is already
allocated". Remove any leftover container unconditionally before starting,
rather than assuming the previous run's cleanup succeeded.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
jsdom 30 dropped support for Node 20 (needs ^22.22.2 || ^24.15.0 || >=26.0.0).
The CI workflow was still pinned to Node 20 from before that dependency bump,
so `npm test` failed in every run since — tests passed locally (on Node 26)
but the pipeline never got past the Test step, so neither of the last two
pushes actually deployed. The Dockerfile's own build stage doesn't need the
same bump: it only runs `npm run build` (tsc + vite), which doesn't touch
jsdom.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Client-side-first PWA (Vite/TS, no backend) per the approved plan: day-
navigable shell listing all 8 hours, Prime fully resolves via the
calendar -> psalter -> ordo pipeline, the other 7 hours are registered
but flagged not-implemented. Sanctoral/temporal calendar data uses a
day -> id indirection layer (saints, easter-offsets, fixed-date-calendar)
so reassigning a feast to a different day is a data edit, not a code
change. Docker (Caddy-serving-static) + Gitea CI workflow scaffolded to
match the eec/drip/bookshop operational pattern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
will