Commit Graph
2 Commits
Author SHA1 Message Date
BBergleandClaude Sonnet 5 6c48000d7b chore(deploy): single-container Dockerfile, Caddy, and Unraid template
CI / Repo hygiene (pull_request) Successful in 2s
CI / Web (lint, typecheck, build) (pull_request) Successful in 15s
CI / Migrations reversible (pull_request) Successful in 6s
CI / API (lint, types, tests) (pull_request) Successful in 53s
Builds the container the "1 container" decision (D15) actually needs, which
D15 itself deferred as follow-up work: Caddy + the FastAPI app + the static
SvelteKit build in one image, SQLite on a mounted volume. See docs/DECISIONS.md
D16 for the specific choices and why (entrypoint-run migrations instead of a
separate deploy-pipeline step, tini + a small supervisor script instead of
s6-overlay/supervisord, copying the Caddy binary out of its official image).

Removes apps/api/Dockerfile and apps/web/Dockerfile from the old 4-container
compose plan (PR #4, closed as superseded) — the root Dockerfile replaces both
with one multi-stage build.

deploy/unraid-template.xml turns VELODROME_PUBLIC_URL, VELODROME_SECRET_KEY,
etc. into fillable Unraid Community Applications web UI fields, per the
earlier decision to keep config there instead of a .env file.

.gitea/workflows/release.yml builds and pushes the image to the Gitea registry
on a version tag or manual dispatch; it does not touch the running container.

Verified by actually running the built image, not just building it: the
health endpoint responds through Caddy's proxy, the SPA serves with working
client-route fallback, alembic ran and produced a real (non-empty) SQLite file
under /data, the process runs as the non-root velodrome user, and killing the
uvicorn process brings the whole container down (exit 143) rather than
leaving Caddy serving alone — confirming the entrypoint's coupled-lifetime
behavior actually holds, not just that it reads correctly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R2ZKeWkZV7ehf7fivrAkkG
2026-09-21 15:55:50 -04:00
BBergleandClaude Opus 5 d5e473959c chore: set up branching, CI, and PR workflow
CI / Repo hygiene (pull_request) Successful in 24s
CI / API (lint, types, tests) (pull_request) Successful in 55s
CI / Web (lint, typecheck, build) (pull_request) Successful in 25s
CI / Migrations reversible (pull_request) Successful in 3s
Prepares the repo for parallel agent work. No application code.

- CLAUDE.md: conventions, branch naming, and the six non-negotiable
  invariants from the design (immutable raw bytes, no stored odometers,
  SI integers, dual-layer user isolation, secret containment, single
  ingestion path). Also records a model-allocation policy: the
  orchestrator runs Opus 5, workers default to Sonnet, and Opus is
  reserved for review plus the areas where a mistake is silent and
  expensive (ingest, wear SQL, auth/RLS, the Bryton protocol client).
  And the Gitea Actions gotchas, so nobody rediscovers them:
  GITEA_TOKEN cannot push to the container registry, jobs.*.environment
  is ignored, and cron needs a workflow_dispatch pair.
- CONTRIBUTING.md: day-to-day flow, worktrees for parallel branches,
  review expectations.
- .gitea/workflows/ci.yml: repo hygiene (branch naming, secret scan,
  no ride data in git), plus API/web/migration jobs that guard on whether
  the code exists yet, so CI is meaningful now and grows into the real
  thing rather than being rewritten.
- .gitea/PULL_REQUEST_TEMPLATE.md: forces an honest "how this was
  verified" and an invariant checklist.
- scripts/pr.sh, scripts/review.sh: open and inspect PRs via the Gitea API.
- Directory scaffold with placeholder READMEs.

Agents open PRs; humans merge them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-20 21:12:22 -04:00