Deploy the dev server from the registry instead of building on the host (#65) #84

Merged
claude-bot merged 1 commit from feat/deploy-from-registry into main 2026-08-31 05:36:30 +00:00
Contributor

Closes #65's repo-side work. Depends on #64 (b252b8f), now merged.

What it adds

docker-compose.registry.yml — runs git.rhoving.com/rbrooks/iris-wled:${IRIS_TAG:-main} instead of building locally.

Two decisions worth stating, both load-bearing:

  • It is deliberately not docker-compose.override.yml. Compose loads an override file automatically, so committing one would silently redirect every user — including anyone following the README quickstart — to a registry image they may not be able to pull. This file is opt-in via -f, or COMPOSE_FILE on a host that always deploys this way. Default docker compose up -d still builds from source.
  • build: !reset null removes the base file's build: section, so Compose can only ever pull this image and can never quietly rebuild it from stale local source. I had flagged the v2.24 requirement as a risk; it's moot — the dev host runs Compose v5.5.0.

IRIS_TAG defaults to main and can be pinned to any :sha-<short> to roll back to a specific commit.

docs/setup.md §6 — the one-time docker login (read-only token: the host only pulls, CI pushes), the git pullcompose pullup -dimage prune sequence, the COMPOSE_FILE shortcut, and rollback.

CHANGELOG.md — also consolidates [Unreleased], which had picked up duplicate Added and Changed headings from my earlier entries. One heading per section now, all 10 entries preserved.

What I found on the dev host

Inspecting claude@10.1.1.14 showed the issue's premise is out of date. It describes switching a live build-on-host deploy over to pulls — but Iris is not running there and has not been since late May:

Checkout 214f8ec, 45 commits behind main, still carries .github/
.env present, but no SESSION_SECRET
data/iris.db 208KB, root:root, 26 May — real schemes/approvals
Registry auth already configured; marginalia and allotrope already pull from git.rhoving.com
Docker / Compose 29.7.2 / v5.5.0
Arch x86_64 — retroactively confirms #79

Two consequences:

  1. docker login is effectively already done — that checkbox on #65 needs verification, not action.
  2. A deploy would hard-fail today. Since #42, docker-compose.yml carries SESSION_SECRET=${SESSION_SECRET:?Set a random SESSION_SECRET}, and the host .env has no such key. That is the #42 fix working exactly as intended, but the host needs a secret generated before anything starts.

Deploy is authorised and follows separately

Bringing Iris up is a physical-world change — WLED_HOST is set, so the scheduler will drive a real controller on the solar schedule. Confirmed with the operator: deploy from the registry image, and back up data/iris.db before letting alembic upgrade head migrate three months forward.

That happens after this merges, and I will report what actually occurred rather than assume it worked.

Closes #65's repo-side work. Depends on #64 (`b252b8f`), now merged. ## What it adds **`docker-compose.registry.yml`** — runs `git.rhoving.com/rbrooks/iris-wled:${IRIS_TAG:-main}` instead of building locally. Two decisions worth stating, both load-bearing: - **It is deliberately not `docker-compose.override.yml`.** Compose loads an override file *automatically*, so committing one would silently redirect every user — including anyone following the README quickstart — to a registry image they may not be able to pull. This file is opt-in via `-f`, or `COMPOSE_FILE` on a host that always deploys this way. Default `docker compose up -d` still builds from source. - **`build: !reset null`** removes the base file's `build:` section, so Compose can only ever pull this image and can never quietly rebuild it from stale local source. I had flagged the v2.24 requirement as a risk; it's moot — the dev host runs **Compose v5.5.0**. `IRIS_TAG` defaults to `main` and can be pinned to any `:sha-<short>` to roll back to a specific commit. **`docs/setup.md` §6** — the one-time `docker login` (read-only token: the host only pulls, CI pushes), the `git pull` → `compose pull` → `up -d` → `image prune` sequence, the `COMPOSE_FILE` shortcut, and rollback. **`CHANGELOG.md`** — also consolidates `[Unreleased]`, which had picked up duplicate `Added` and `Changed` headings from my earlier entries. One heading per section now, all 10 entries preserved. ## What I found on the dev host Inspecting `claude@10.1.1.14` showed the issue's premise is out of date. It describes switching a live build-on-host deploy over to pulls — but **Iris is not running there and has not been since late May**: | | | |---|---| | Checkout | `214f8ec`, **45 commits behind** `main`, still carries `.github/` | | `.env` | present, but **no `SESSION_SECRET`** | | `data/iris.db` | 208KB, `root:root`, 26 May — real schemes/approvals | | Registry auth | **already configured**; marginalia and allotrope already pull from `git.rhoving.com` | | Docker / Compose | 29.7.2 / v5.5.0 | | Arch | x86_64 — retroactively confirms #79 | Two consequences: 1. **`docker login` is effectively already done** — that checkbox on #65 needs verification, not action. 2. **A deploy would hard-fail today.** Since #42, `docker-compose.yml` carries `SESSION_SECRET=${SESSION_SECRET:?Set a random SESSION_SECRET}`, and the host `.env` has no such key. That is the #42 fix working exactly as intended, but the host needs a secret generated before anything starts. ## Deploy is authorised and follows separately Bringing Iris up is a physical-world change — `WLED_HOST` is set, so the scheduler will drive a real controller on the solar schedule. Confirmed with the operator: deploy from the registry image, and **back up `data/iris.db` before letting `alembic upgrade head` migrate three months forward**. That happens after this merges, and I will report what actually occurred rather than assume it worked.
Deploy the dev server from the registry instead of building on the host (#65)
All checks were successful
CI / Alembic migration check (pull_request) Successful in 33s
CI / Python lint & type-check (pull_request) Successful in 59s
CI / Python tests (pull_request) Successful in 1m46s
CI / Frontend lint, test & build (pull_request) Successful in 2m55s
CI / Docker build, health smoke & E2E (pull_request) Successful in 3m20s
846cb3a8d8
Adds docker-compose.registry.yml, which runs
git.rhoving.com/rbrooks/iris-wled:${IRIS_TAG:-main} rather than building
locally, and documents the deploy sequence in docs/setup.md section 6.

Deliberately NOT named docker-compose.override.yml. Compose loads an override
file automatically, so committing one would silently redirect every user --
including anyone following the README quickstart -- to a registry image they may
not be able to pull. This file is opt-in via -f, or COMPOSE_FILE on a host that
always deploys this way. The default `docker compose up -d` still builds from
source.

build: !reset null removes the base file's build section so Compose can only
pull, never quietly rebuild from stale local source. Confirmed supported: the
dev host runs Compose v5.5.0, well past the v2.24 that !reset needs.

IRIS_TAG defaults to main and can be pinned to a :sha-<short> tag to roll back
to a specific commit's image.

Also consolidates CHANGELOG [Unreleased], which had picked up duplicate "Added"
and "Changed" headings from my earlier entries. One heading per section now; all
entries preserved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
claude-bot deleted branch feat/deploy-from-registry 2026-08-31 05:36:30 +00:00
Sign in to join this conversation.
No description provided.