deploy: pull prebuilt registry images in compose (IMAGE_TAG) + dev/prod split #54

wtclaude · 2026-07-11T23:34:55Z

wtclaude commented

2026-07-11 23:34:55 +00:00

What

Now that the build workflow publishes app + bot images to the Gitea registry, make docker-compose.yml production-shaped — it pulls the prebuilt images and never builds — with local builds moved to an explicit dev overlay.

docker-compose.yml (production): image: only, no build:

app:
  image: gitea.whitlocktech.com/uom/website-app:${IMAGE_TAG:-latest}
bot:
  image: gitea.whitlocktech.com/uom/website-bot:${IMAGE_TAG:-latest}

docker-compose.dev.yml (new, explicit — not auto-loaded): adds build: back

services:
  app:  { build: . }
  bot:  { build: { context: ., dockerfile: bot/Dockerfile } }

Why the split

With build: and image: both in one file, Compose gives build precedence for up --build/build, mixing two deployment modes and letting a production host accidentally build. Keeping build: out of the base file makes that impossible — production can only pull.

Usage

# Production
docker compose pull && docker compose up -d
IMAGE_TAG=sha-042a151 docker compose pull && docker compose up -d   # pin / rollback

# Development (build locally)
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

Tagging

Image tag is the IMAGE_TAG env var (default latest; pin to an immutable sha-<7> for reproducible deploys / rollback). Keeping the workflow's existing latest + sha-<7> tags — no auto-semver on merge (that implies human intent; add a v* git-tag trigger later if formal releases are wanted). New IMAGE_TAG documented in .env.example; README quick-start updated to the two-file flow.

Verified

docker compose config renders the base as image-only, no build for both services, and the dev overlay adds build: back (app → Dockerfile, bot → bot/Dockerfile), with IMAGE_TAG interpolating for both the default and a pinned value.

🤖 Generated with Claude Code

https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ

## What Now that the build workflow publishes `app` + `bot` images to the Gitea registry, make `docker-compose.yml` **production-shaped** — it pulls the prebuilt images and **never builds** — with local builds moved to an explicit dev overlay. **`docker-compose.yml`** (production): `image:` only, no `build:` ```yaml app: image: gitea.whitlocktech.com/uom/website-app:${IMAGE_TAG:-latest} bot: image: gitea.whitlocktech.com/uom/website-bot:${IMAGE_TAG:-latest} ``` **`docker-compose.dev.yml`** (new, explicit — not auto-loaded): adds `build:` back ```yaml services: app: { build: . } bot: { build: { context: ., dockerfile: bot/Dockerfile } } ``` ## Why the split With `build:` and `image:` both in one file, Compose gives `build` precedence for `up --build`/`build`, mixing two deployment modes and letting a production host accidentally build. Keeping `build:` out of the base file makes that impossible — production can only pull. ## Usage ```bash # Production docker compose pull && docker compose up -d IMAGE_TAG=sha-042a151 docker compose pull && docker compose up -d # pin / rollback # Development (build locally) docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build ``` ## Tagging Image tag is the `IMAGE_TAG` env var (default `latest`; pin to an immutable `sha-<7>` for reproducible deploys / rollback). Keeping the workflow's existing `latest` + `sha-<7>` tags — no auto-semver on merge (that implies human intent; add a `v*` git-tag trigger later if formal releases are wanted). New `IMAGE_TAG` documented in `.env.example`; README quick-start updated to the two-file flow. ## Verified `docker compose config` renders the base as **image-only, no build** for both services, and the dev overlay adds `build:` back (app → `Dockerfile`, bot → `bot/Dockerfile`), with `IMAGE_TAG` interpolating for both the default and a pinned value. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ

wtclaude added 1 commit 2026-07-11 23:34:56 +00:00

deploy: pull prebuilt registry images in compose (IMAGE_TAG) 25ff5aa836

Point the `app` and `bot` services at the images published to the Gitea
registry by the build-images workflow, so deploys pull instead of building:

  image: gitea.whitlocktech.com/uom/website-app:${IMAGE_TAG:-latest}
  image: gitea.whitlocktech.com/uom/website-bot:${IMAGE_TAG:-latest}

`build:` is kept, so `up --build` still works locally; the server runs
`docker compose pull && up -d`. IMAGE_TAG defaults to `latest` for routine
deploys and pins to an immutable `sha-<7>` build for reproducible deploys /
rollback — no per-deploy compose edits. Documented in .env.example + README.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ

whitlocktech approved these changes 2026-07-11 23:36:48 +00:00

whitlocktech merged commit 3628268dda into main

2026-07-11 23:36:57 +00:00

whitlocktech deleted branch deploy/compose-use-registry-images

2026-07-11 23:36:58 +00:00

whitlocktech referenced this issue from a commit

2026-07-11 23:36:58 +00:00

Merge pull request 'deploy: pull prebuilt registry images in compose (IMAGE_TAG)' (#54) from deploy/compose-use-registry-images into main

wtclaude changed title from ~~deploy: pull prebuilt registry images in compose (IMAGE_TAG)~~ to deploy: pull prebuilt registry images in compose (IMAGE_TAG) + dev/prod split

2026-07-11 23:42:45 +00:00

wtclaude referenced this pull request

2026-07-11 23:44:02 +00:00

deploy: split build into docker-compose.dev.yml (prod compose pulls only) #55

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/website#54