[Ops] Publish versioned Docker images from CI #91

New issue

Closed

opened 2026-07-14 19:47:43 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-14 19:47:43 +00:00

Contributor

Context

The repo has 25 semver tags and a tag-triggered release workflow that extracts release notes (.forgejo/workflows/release.yml) — but no container images are ever published. Every deploy and every self-hoster builds all three prod targets from source.

Motivation

Building from source means a slow first run, no immutable artifacts to roll back to, and no way to pin a deployment to exactly what was tested. Published per-version images make upgrades and rollbacks a tag change.

Fix / Spec

Extend the tag-push workflow (or add a job to release.yml) to build the three prod targets from the unified Dockerfile: backend-prod, frontend-prod, bot-prod.
Push to the Forgejo container registry at git.rhoving.com as:
- git.rhoving.com/rbrooks/quest-board-backend:{version} and :latest
- git.rhoving.com/rbrooks/quest-board-frontend:{version} and :latest
- git.rhoving.com/rbrooks/quest-board-bot:{version} and :latest
Registry auth via CI secrets — document the exact secret names used (e.g. REGISTRY_USER / REGISTRY_TOKEN) and required scopes in the workflow comments and OPERATIONS.md.
Update README.md / docs/OPERATIONS.md with a compose override example that consumes the published images (image: replacing build:) for self-hosters.
Optional: a Trivy scan job on the built images — advisory (non-gating) to start.

Acceptance criteria

Pushing a semver tag produces pullable images for all three components at both {version} and latest.
The documented compose override boots the full stack from the registry with no local build.
Secret names and setup are documented.

References

.forgejo/workflows/release.yml
Dockerfile (multi-stage targets backend-prod, frontend-prod, bot-prod)

Filed from the July 2026 full-project review.

## Context The repo has 25 semver tags and a tag-triggered release workflow that extracts release notes (`.forgejo/workflows/release.yml`) — but no container images are ever published. Every deploy and every self-hoster builds all three prod targets from source. ## Motivation Building from source means a slow first run, no immutable artifacts to roll back to, and no way to pin a deployment to exactly what was tested. Published per-version images make upgrades and rollbacks a tag change. ## Fix / Spec 1. Extend the tag-push workflow (or add a job to `release.yml`) to build the three prod targets from the unified `Dockerfile`: `backend-prod`, `frontend-prod`, `bot-prod`. 2. Push to the Forgejo container registry at `git.rhoving.com` as: - `git.rhoving.com/rbrooks/quest-board-backend:{version}` and `:latest` - `git.rhoving.com/rbrooks/quest-board-frontend:{version}` and `:latest` - `git.rhoving.com/rbrooks/quest-board-bot:{version}` and `:latest` 3. Registry auth via CI secrets — document the exact secret names used (e.g. `REGISTRY_USER` / `REGISTRY_TOKEN`) and required scopes in the workflow comments and OPERATIONS.md. 4. Update `README.md` / `docs/OPERATIONS.md` with a compose override example that consumes the published images (`image:` replacing `build:`) for self-hosters. 5. Optional: a Trivy scan job on the built images — advisory (non-gating) to start. ## Acceptance criteria - [ ] Pushing a semver tag produces pullable images for all three components at both `{version}` and `latest`. - [ ] The documented compose override boots the full stack from the registry with no local build. - [ ] Secret names and setup are documented. ## References - `.forgejo/workflows/release.yml` - `Dockerfile` (multi-stage targets `backend-prod`, `frontend-prod`, `bot-prod`) _Filed from the July 2026 full-project review._

claude-bot added the

enhancement

label

2026-07-14 19:47:51 +00:00

claude-bot added this to the v3.4.0 - Reliability, Operations & Self-Hosting milestone

2026-07-14 19:47:52 +00:00