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

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
parent 1832059e03
commit 5d4d76203f
5 changed files with 291 additions and 0 deletions
@@ -0,0 +1,52 @@
+name: Release
+
+on:
+  push:
+    tags: ['v*']
+  workflow_dispatch:
+
+jobs:
+  build-and-push:
+    name: Build and push images
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Determine image tag
+        id: tag
+        run: |
+          if [ "${{ gitea.ref_type }}" = "tag" ]; then
+            echo "tag=${{ gitea.ref_name }}" >> "$GITHUB_OUTPUT"
+          else
+            echo "tag=manual-$(date -u +%Y%m%d%H%M%S)" >> "$GITHUB_OUTPUT"
+          fi
+
+      - uses: docker/setup-buildx-action@v3
+
+      # NOT secrets.GITEA_TOKEN — it cannot push to the Gitea container registry (documented
+      # Gitea limitation, see CLAUDE.md). REGISTRY_TOKEN is a separate PAT with `package:write`
+      # scope that a human must create in Settings -> Applications and add as a repo Actions
+      # secret before this workflow can succeed.
+      - uses: docker/login-action@v3
+        with:
+          registry: 192.168.0.3:3000
+          username: ${{ gitea.actor }}
+          password: ${{ secrets.REGISTRY_TOKEN }}
+
+      - name: Build and push API image
+        uses: docker/build-push-action@v6
+        with:
+          context: apps/api
+          push: true
+          tags: |
+            192.168.0.3:3000/bbergle/velodrome-api:${{ steps.tag.outputs.tag }}
+            192.168.0.3:3000/bbergle/velodrome-api:latest
+
+      - name: Build and push web image
+        uses: docker/build-push-action@v6
+        with:
+          context: apps/web
+          push: true
+          tags: |
+            192.168.0.3:3000/bbergle/velodrome-web:${{ steps.tag.outputs.tag }}
+            192.168.0.3:3000/bbergle/velodrome-web:latest