v0.2: Publish Docker image to a registry #12

New issue

Closed

opened 2026-05-03 14:53:37 -04:00 by zgaetano · 0 comments

zgaetano commented

2026-05-03 14:53:37 -04:00

Owner

Today the deploy quick-start says docker compose up -d --build, which means anyone deploying rebuilds from source. That works for a single-operator deploy but it's friction-heavy for any kind of repeatable rollout, and the v0.1.0-dragonfork tag has no published artifact behind it.

Scope

CI workflow that builds dragonfork-core:${TAG} on tag push (v*-dragonfork)
Push to a registry — likely forge.wilddragon.net's container registry if it has one, else the GitHub Container Registry mirror, else Docker Hub. Decide at design time.
Multi-arch (linux/amd64 + linux/arm64) — upstream Datarhei does linux/arm/v8 too; v0.2 can stick to amd64+arm64 for now since TrueNAS is amd64.
README quick-start updated to docker pull + docker compose up -d (no --build)
Compose file references the published image by default, with build: block kept as a fallback for source builds

Why now

The metrics work in the observability issue will add new images (Prom + Grafana from upstream), and the rollout doc already starts saying "docker compose pull". That sentence only works if Core is also pullable. Closes that small but visible gap.

Open questions for design

Which registry? Forge's own, GHCR, Docker Hub?
Tag scheme — v0.2.0-dragonfork only, or also a rolling latest and main?
CI runner — existing Forgejo Actions or self-hosted?
Image signing (cosign) — out of scope for v0.2?

Needs a short design doc before implementation.

Today the deploy quick-start says `docker compose up -d --build`, which means anyone deploying rebuilds from source. That works for a single-operator deploy but it's friction-heavy for any kind of repeatable rollout, and the v0.1.0-dragonfork tag has no published artifact behind it. ## Scope - CI workflow that builds `dragonfork-core:${TAG}` on tag push (`v*-dragonfork`) - Push to a registry — likely `forge.wilddragon.net`'s container registry if it has one, else the GitHub Container Registry mirror, else Docker Hub. Decide at design time. - Multi-arch (linux/amd64 + linux/arm64) — upstream Datarhei does linux/arm/v8 too; v0.2 can stick to amd64+arm64 for now since TrueNAS is amd64. - README quick-start updated to `docker pull` + `docker compose up -d` (no `--build`) - Compose file references the published image by default, with `build:` block kept as a fallback for source builds ## Why now The metrics work in the observability issue will add new images (Prom + Grafana from upstream), and the rollout doc already starts saying "docker compose pull". That sentence only works if Core is also pullable. Closes that small but visible gap. ## Open questions for design 1. Which registry? Forge's own, GHCR, Docker Hub? 2. Tag scheme — `v0.2.0-dragonfork` only, or also a rolling `latest` and `main`? 3. CI runner — existing Forgejo Actions or self-hosted? 4. Image signing (cosign) — out of scope for v0.2? Needs a short design doc before implementation.