feat(ci): publish versioned Docker images from CI on tag (#91) #164
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/91-publish-images"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Every deploy and self-hoster built all three prod targets from source — slow first run, no immutable artifacts to roll back to, no way to pin to exactly what was tested. This publishes per-version images on tag.
Changes
.forgejo/workflows/release.yml: newimagesjob (runs onvX.Y.Ztag push) — buildsbackend-prod,frontend-prod,bot-prodfrom the unified Dockerfile and pushes togit.rhoving.com/rbrooks/quest-board-{backend,frontend,bot}.v3.4.0→3.4.0);:latestmoves only for final releases, not prereleases (v3.4.0-rc1→ version tag only).REGISTRY_USERandREGISTRY_TOKEN(write:packagescope). Documented in the workflow and in OPERATIONS.md. These must be created before the first tagged release or theimagesjob fails atdocker login.docker-compose.images.ymloverride example (image:replacingbuild:, pin all services to one tag); README points to it.Verification
release.ymlparses as valid YAML.v3.4.0→3.4.0+latest;v3.4.0-rc1→3.4.0-rc1only.backend-prod/frontend-prod/bot-prod) exist in the Dockerfile and are already built by the CIdockerjob on every PR.Note: the job only runs on tag push, so it isn't exercised by PR CI. First real validation is the next
vX.Y.Ztag (after the secrets are set).Closes #91
🤖 Generated with Claude Code
Every deploy and self-hoster built all three prod targets from source — slow first run, no immutable artifacts to roll back to, no way to pin a deployment to exactly what was tested. Add an `images` job to the tag-triggered release workflow that builds backend-prod, frontend-prod, and bot-prod from the unified Dockerfile and pushes them to the Forgejo container registry as git.rhoving.com/rbrooks/quest-board-{backend,frontend,bot}. Each gets the version tag (vX.Y.Z -> X.Y.Z); :latest moves only for final releases, not prereleases. The job is independent of the release-notes job, so a missing registry secret doesn't block the release. Auth uses two Actions secrets (REGISTRY_USER / REGISTRY_TOKEN with the write:package scope) — documented in the workflow and OPERATIONS.md. OPERATIONS.md also gains a "Running from Published Images" section with a docker-compose.images.yml override example; README points to it. Closes #91 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>