Record what the layer cache measured: 23s warm, against a 7m34s baseline

[Peeja]

⏭️ Safe to merge without waiting for CI — all of it

Refreshed on every push. Checks are not required yet, so this is advice, not a gate.

One file changed: MONOREPO_TODO.md. Nothing in the repository reads it.

$ git diff --name-only origin/main HEAD
MONOREPO_TODO.md
$ grep -rn "MONOREPO_TODO" --include='*.yml' --include='*.sh' --include='*.go' --include=Makefile .
.github/scripts/check-base-images.sh:12:# not installed yet (MONOREPO_TODO.md), so that half is inert. This check is

One hit, prose inside a comment. No workflow, guard, Go package or Makefile target consumes the file.

What this costs if it's wrong: the checks still run; we just don't wait. If an ignored check goes red after merge, main is red.

---

The entry landed by #23 said to re-measure the layer cache after a warm run. That number arrived sooner than expected, so this records it.

Why it arrived early: #25's e2e job hit the pre-existing TestUploadAndRetrieve/filesystem flake, I re-ran it once — and a pull request writes its own cache scope, so the re-run read back what run 1 wrote. The flake handed us the warm measurement.

The numbers

all 8 images
baseline, plain docker build	7m34s (itest ingot), 6m08s (itest hilt)
cold + cache write	11m21s — ~3 min worse
warm	23s

build piri 4s · hilt 5s · ingot 3s · sprue 2s · delegator 2s
      piri-signing-service 2s · swarf 3s · indexing-service 2s

The whole e2e job went 13m10s → 5m29s.

Three caveats, recorded with the number rather than under it

1. The warm figure is a re-run of the same commit, so every layer hit. That is the ceiling, not the average. A real change invalidates the go build layer for the services it touches; the base image, apt and go mod download layers — the bulk — still hit, so expect minutes rather than seconds. The entry says to re-measure on a real source change.
2. The cold path is ~3 minutes worse than before, because mode=max exports every layer. The first run on main after Layer-cache the image builds in itest and e2e, keeping images.yml cold #25 merges will be slower, by construction.
3. Nobody has checked the cache against GitHub's 10 GB per-repository limit. Eight images at mode=max is not small, eviction is LRU, and an overflowing cache degrades quietly back to cold builds — which is exactly the kind of silent regression this repo keeps deleting.

One option dies as a consequence

Build-once-and-load was the other way at the same ~6 minutes: have images.yml hand its images over as an artifact. The entry already said "try the cache first". 23 seconds is below anything a 1–2 GB artifact round-trip could achieve, so it is now marked effectively dead — it only comes back if the cache turns out to evict often.

Worth your eye

The 10 GB limit is the one I'd actually check before treating 23 seconds as durable. I have not, and the entry says so rather than implying otherwise.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CGAGAib517Ae1kg8SCdcEt

---

Generated by Claude Code