BBergle/bike-app
Public Access
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(deploy): compose stack, Caddy, and the release/deploy pipeline #4

Closed
BBergle wants to merge 2 commits from feat/deploy-pipeline into main
pull from: feat/deploy-pipeline
merge into: :main
Conversation 1 Commits 2 Files Changed 5
+296
2 Commits
Author SHA1 Message Date
BBergleandClaude Opus 5 4f4ca345ca fix(deploy): healthcheck must hit the real host IP, not localhost
CI / Repo hygiene (pull_request) Successful in 1s
Details
CI / Web (lint, typecheck, build) (pull_request) Successful in 15s
Details
CI / Migrations reversible (pull_request) Successful in 9s
Details
CI / API (lint, types, tests) (pull_request) Successful in 54s
Details 
The deploy job runs inside its own ephemeral DooD job container, which is a
separate container from `caddy` — caddy's -p 8090:80 publishes onto the real
host's network namespace, not this job container's own loopback. A
`localhost:8090` curl here would fail with connection-refused regardless of
whether the deploy actually succeeded, misreporting a working deploy as a
failed workflow. Point it at the same host IP deploy/.env.example's
VELODROME_PUBLIC_URL already uses.

Caught during review, not left as the open caveat the PR description flagged
it as.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-21 15:11:33 -04:00
BBergleandClaude Sonnet 5 5d4d76203f feat(deploy): compose stack, Caddy, and the release/deploy pipeline
CI / Repo hygiene (pull_request) Successful in 3s
Details
CI / Web (lint, typecheck, build) (pull_request) Successful in 16s
Details
CI / Migrations reversible (pull_request) Successful in 7s
Details
CI / API (lint, types, tests) (pull_request) Successful in 55s
Details 
Phase 0 deployment: three-service docker-compose.yml (caddy, api, db), a
Caddyfile that proxies /api/* to the api service and serves the SPA with
index.html fallback, and two Gitea Actions workflows (release.yml builds and
pushes both images on a v* tag or manual dispatch; deploy.yml is manual-only
and rolls them out to the Unraid host).

The non-obvious part is the Docker-outside-of-Docker constraint on this
act_runner setup: job containers share the host's Docker daemon over the
socket but do NOT share its filesystem, so any command whose correctness
depends on a client-side local path (docker cp to a host path, mv/rm -rf on
a host path, a bind-mount source path on a `docker run` command line issued
from inside a job) silently operates on the ephemeral job container's own
throwaway filesystem instead. Two things are safe: a bind mount declared in
a compose file's `volumes:` block (resolved by the daemon when `docker
compose up` creates the service — this is why db's pgdata bind mount is
fine), and a named volume populated by a one-shot `docker run` whose
*command* does the copying (this is why the web image's static build output
goes into a `web_build` named volume via `docker run -v ... sh -c 'cp -a
...'` in deploy.yml, rather than any `docker cp`).

Local verification (see PR description for full detail) caught a real bug:
`docker compose run api alembic upgrade head` needs
VELODROME_DB_APP_PASSWORD/VELODROME_DB_AUTH_PASSWORD as container env vars
to create the two runtime roles, but --env-file alone doesn't inject them
since the api service's permanent environment block deliberately omits them
(least-privilege — the long-running app should never need role-creation
passwords). Fixed by passing them as explicit -e overrides on the migration
step, same as VELODROME_DATABASE_URL_MIGRATE.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-21 15:07:10 -04:00