Deploy the dev server from registry images (compose pull) instead of building on the host

claude-bot commented

2026-07-15 15:42:25 +00:00

Contributor

Today the dev server (claude@10.1.1.14) deploys with git pull && docker compose build --no-cache && docker compose down && docker compose up -d. Host builds are slow, have caused real incidents (the disk filled to 100% with build caches during M2, and a mistagged manual build once left a stale container running), and duplicate work CI already does.

Switch to pulling the CI-built image:

Compose override for the dev host (docker-compose.override.yml or a dedicated file) replacing build: with image: git.rhoving.com/rbrooks/iris-wled:main
docker login git.rhoving.com on the host with a minimal-scope token (package read)
New deploy sequence: git pull (compose/config only) && docker compose pull && docker compose up -d, then docker image prune -f for superseded images
Document in docs/setup.md (or a dev-ops note) and retire the build-on-host instructions
Optional next step: full CD — a workflow job (or webhook + watchtower-style puller) that runs the pull+up on the host after :main publishes, making deploys automatic

Depends on: the :main image publishing issue.

Today the dev server (claude@10.1.1.14) deploys with `git pull && docker compose build --no-cache && docker compose down && docker compose up -d`. Host builds are slow, have caused real incidents (the disk filled to 100% with build caches during M2, and a mistagged manual build once left a stale container running), and duplicate work CI already does. Switch to pulling the CI-built image: - [ ] Compose override for the dev host (`docker-compose.override.yml` or a dedicated file) replacing `build:` with `image: git.rhoving.com/rbrooks/iris-wled:main` - [ ] `docker login git.rhoving.com` on the host with a minimal-scope token (package read) - [ ] New deploy sequence: `git pull` (compose/config only) && `docker compose pull` && `docker compose up -d`, then `docker image prune -f` for superseded images - [ ] Document in docs/setup.md (or a dev-ops note) and retire the build-on-host instructions - [ ] Optional next step: full CD — a workflow job (or webhook + watchtower-style puller) that runs the pull+up on the host after `:main` publishes, making deploys automatic Depends on: the `:main` image publishing issue.

claude-bot added this to the v1.0.0 milestone

2026-07-15 15:42:25 +00:00

claude-bot added the

labels

2026-07-15 15:42:25 +00:00

claude-bot referenced this issue

2026-07-15 15:42:25 +00:00

CI: publish a :main image to the Forgejo registry on every push to main #64

claude-bot commented

2026-07-15 15:42:25 +00:00

Author

Contributor

Depends on #64.

claude-bot referenced this issue

2026-07-15 15:42:26 +00:00

Wire priority_resolver into push paths — date pins & Promote Secondary have no runtime effect #43

claude-bot referenced this issue

2026-07-15 15:42:26 +00:00

Honor the no-event default_scheme setting (off / dim_white / scheme reference) #44

claude-bot referenced this issue

2026-07-15 15:42:26 +00:00

Finish fallback policies: 5-minute spaced retries and last_known_good re-push on reconnect #45

claude-bot referenced this issue

2026-07-15 15:42:27 +00:00

Revert quick-push at the on scheduler event #47

claude-bot referenced this issue

2026-07-16 05:23:24 +00:00

Security: plumb SESSION_SECRET into docker-compose and .env.example #42

rbrooks referenced this issue from a commit

2026-08-31 04:27:08 +00:00

CI: publish :main and :sha-<short> on every merge to main (#64)

claude-bot referenced this issue

2026-08-31 04:27:18 +00:00

CI: publish :main and :sha-* images on every merge to main (#64) #83

claude-bot referenced this issue from a commit

2026-08-31 04:49:21 +00:00

CI: publish :main and :sha-* images on every merge to main (#64)

rbrooks referenced this issue from a commit

2026-08-31 04:50:22 +00:00

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

claude-bot referenced this issue from a pull request that will close it,

2026-08-31 04:50:37 +00:00

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

claude-bot closed this issue

2026-08-31 05:36:30 +00:00

claude-bot referenced this issue from a commit

2026-08-31 05:36:31 +00:00

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

claude-bot commented

2026-08-31 05:42:07 +00:00

Author

Contributor

Done — mechanism proven end to end on the dev host

Shipped in 18acc22.

docker-compose.registry.yml runs git.rhoving.com/rbrooks/iris-wled:${IRIS_TAG:-main}
docs/setup.md §6 documents login, deploy, COMPOSE_FILE, and rollback
build-on-host instructions retired in favour of the pull path

Deployed and verified:

Container iris   git.rhoving.com/rbrooks/iris-wled:main   Up (healthy)
{"status":"ok"}

docker compose config resolved to image: with no build: key, confirming build: !reset null works — Compose structurally cannot rebuild from stale local source. The host runs Compose v5.5.0, so the v2.24 requirement was never a risk.

Data survived the migration: 97 events, 169 schemes. A byte-identical backup (md5 verified) was taken before anything ran: data/iris.db.pre-redeploy-20260831-053637.

The issue's premise was out of date

This was written as switching a live build-on-host deploy over to pulls. In fact Iris had not been running on the dev host since late May — the checkout was 45 commits behind and still carried .github/. So this was a cold restart onto a new mechanism, not a cutover.

Two findings:

docker login was already done. git.rhoving.com was already in ~/.docker/config.json; marginalia and allotrope already pull from it. That checkbox needed verification, not action.
The deploy would have hard-failed on the missing SESSION_SECRET — #42's guard doing exactly its job. A secret was generated on the host (openssl rand -hex 32), appended to .env after backing it up, and never echoed.

Migrations were smaller than expected

Only 0006 → 0007 → 0008 ran. The May database was already at 0006, so two migrations applied rather than the eight-from-scratch I had braced for. No errors.

What remains is configuration, not deployment

The instance is up but inert:

LATITUDE = EMPTY   LONGITUDE = EMPTY   WLED_HOST = EMPTY
WARNING  Cannot schedule today's jobs: LATITUDE and LONGITUDE must be set for SCHEDULE_MODE=solar

segments, settings and audit_log are all 0 rows — this instance was never configured past event/scheme generation. No scheduler jobs are registered and no controller is configured, so nothing touches any lights.

That is configuration a human supplies, not deployment work, so it is recorded on #7 (end-to-end operational dry run) where the setup belongs rather than held open here.

## Done — mechanism proven end to end on the dev host Shipped in `18acc22`. - `docker-compose.registry.yml` runs `git.rhoving.com/rbrooks/iris-wled:${IRIS_TAG:-main}` - `docs/setup.md` §6 documents login, deploy, `COMPOSE_FILE`, and rollback - build-on-host instructions retired in favour of the pull path **Deployed and verified:** ``` Container iris git.rhoving.com/rbrooks/iris-wled:main Up (healthy) {"status":"ok"} ``` `docker compose config` resolved to `image:` with **no `build:` key**, confirming `build: !reset null` works — Compose structurally cannot rebuild from stale local source. The host runs Compose v5.5.0, so the v2.24 requirement was never a risk. Data survived the migration: **97 events, 169 schemes**. A byte-identical backup (`md5` verified) was taken before anything ran: `data/iris.db.pre-redeploy-20260831-053637`. ### The issue's premise was out of date This was written as switching a *live* build-on-host deploy over to pulls. In fact **Iris had not been running on the dev host since late May** — the checkout was 45 commits behind and still carried `.github/`. So this was a cold restart onto a new mechanism, not a cutover. Two findings: - **`docker login` was already done.** `git.rhoving.com` was already in `~/.docker/config.json`; marginalia and allotrope already pull from it. That checkbox needed verification, not action. - **The deploy would have hard-failed** on the missing `SESSION_SECRET` — #42's guard doing exactly its job. A secret was generated on the host (`openssl rand -hex 32`), appended to `.env` after backing it up, and never echoed. ### Migrations were smaller than expected Only `0006 → 0007 → 0008` ran. The May database was already at `0006`, so two migrations applied rather than the eight-from-scratch I had braced for. No errors. ### What remains is configuration, not deployment The instance is up but **inert**: ``` LATITUDE = EMPTY LONGITUDE = EMPTY WLED_HOST = EMPTY WARNING Cannot schedule today's jobs: LATITUDE and LONGITUDE must be set for SCHEDULE_MODE=solar ``` `segments`, `settings` and `audit_log` are all 0 rows — this instance was never configured past event/scheme generation. No scheduler jobs are registered and no controller is configured, so nothing touches any lights. That is configuration a human supplies, not deployment work, so it is recorded on #7 (end-to-end operational dry run) where the setup belongs rather than held open here.

claude-bot referenced this issue

2026-08-31 05:42:22 +00:00

Final QA: end-to-end operational dry run #7

~~claude-bot referenced this issue 2026-08-31 05:45:41 +00:00~~

CI: stop leaving our own images on the shared runner #86

claude-bot referenced this issue

2026-09-01 15:53:12 +00:00

Production deployment via the Ansible/IaC repo; Iris builds and publishes only #104