From c8413c11089da7b0a6c2254d868480bb16833953 Mon Sep 17 00:00:00 2001 From: thesabear Date: Fri, 28 Aug 2026 21:36:04 +0300 Subject: [PATCH] registry-and-build: add real evidence for the 36/41 count and mariadb-mirror mechanism Step 5 re-audit. Both were verified live earlier this session but never shown - the strategy breakdown backs the doc's own headline stat directly, and the mariadb-latest entry proves the specific shared-mirror mechanism rather than just describing it. --- docs/registry-and-build.md | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/docs/registry-and-build.md b/docs/registry-and-build.md index bd9adea..8b018a3 100644 --- a/docs/registry-and-build.md +++ b/docs/registry-and-build.md @@ -28,7 +28,15 @@ This is the real registry, not a claim about it — every one of these is a genu ## Deliberate holdouts -Not every stack is on this pattern, and that's a decision, not an oversight — knowing when *not* to apply a pattern uniformly is as much a design skill as building the pattern in the first place: +Not every stack is on this pattern, and that's a decision, not an oversight — knowing when *not* to apply a pattern uniformly is as much a design skill as building the pattern in the first place. This is the real breakdown, not a rounded estimate: + +``` +$ python3 -c "import yaml; d=yaml.safe_load(open('docker_stacks.yml'))['stacks']; ..." +total: 41 +dockerfile 36 +pinned_manual 3 +latest 2 +``` | Stack | Why it's held out | |---|---| @@ -36,7 +44,18 @@ Not every stack is on this pattern, and that's a decision, not an oversight — | Kodi's own app image | Genuinely still a direct Docker Hub dependency — low enough stakes that the extra build step isn't worth it | | Nextcloud's own `nextcloud`/`euro-office` services | Pre-existing custom Dockerfiles, left as-is beyond adding `image:` references — its own db/redis still float on Docker Hub tags directly, a conscious "don't touch what already works" call | -Two more things that look like holdouts but aren't: `docker-socket-proxy` and Kodi's own `mariadb` service both run on `strategy: latest`, but neither actually depends on Docker Hub at runtime — each floats a `:latest` pull against a small dedicated mirror stack (`docker-socket-proxy-mirror`, `mariadb-latest`) that *is* built in-fleet via the normal pattern. It's a deliberate variant for lightweight consumer containers: one real build feeds every stack that needs that base image, instead of each one maintaining its own near-identical Dockerfile. +Two more things that look like holdouts but aren't: `docker-socket-proxy` and Kodi's own `mariadb` service both run on `strategy: latest`, but neither actually depends on Docker Hub at runtime — each floats a `:latest` pull against a small dedicated mirror stack (`docker-socket-proxy-mirror`, `mariadb-latest`) that *is* built in-fleet via the normal pattern. It's a deliberate variant for lightweight consumer containers: one real build feeds every stack that needs that base image, instead of each one maintaining its own near-identical Dockerfile. This is the real entry, not a description of the pattern: + +``` +$ grep -A6 "^ mariadb-latest:" docker_stacks.yml +mariadb-latest: + strategy: dockerfile + upstream_image: lscr.io/linuxserver/mariadb:latest + notes: >- + Not a real database - nothing connects to it directly. Exists purely + to be built and pushed so every stack needing a MariaDB (bookstack, + firefly iii, kodi) pulls from our registry instead of Docker Hub. +``` ## Trigger discipline