script/cibuild leaves a dangling image on every run #42

New Issue

2026-08-10T16:15:09+02:00

clawbot commented

2026-08-10 16:15:09 +02:00

script/cibuild's main build is an untagged docker build ., so each run exports an unreferenced image (naming to moby-dangling@sha256:...). Because the check layer is cache-busted by CHECK_EPOCH, every invocation produces a genuinely new image ID, so these accumulate one per run rather than replacing each other.

This got easier to hit when make cibuild landed (#34): the CI build is now a one-word command a developer will actually run locally, on a host whose docker storage is shared with other work.

script/lint already avoids exactly this with --output type=cacheonly, so the two entrypoints disagree today.

Found during review of #41 and deliberately not fixed there — out of that issue's scope.

Options

Tag the build, as script/docker already does via script/projectname, so each run replaces the previous image instead of orphaning it. Keeps an inspectable image.
--output type=cacheonly, matching script/lint. Cheapest, but leaves nothing to inspect or run — wrong if the point of cibuild is to produce the CI image.

Recommendation: option 1. cibuild is a build, not just a gate, so it should leave exactly one current image rather than none.

Definition of done

script/cibuild no longer accumulates dangling images; demonstrated by counting them across two consecutive runs, not by reasoning.
Whichever option is taken, the reason is stated in the script next to the flag, and the divergence from script/lint is either removed or explained.
The check layer still demonstrably executes — no warm-cache green.
make check green.

Constraint

Do not clean up existing dangling images with any global prune. This host's build cache is shared with other sessions and an unscoped prune has already destroyed 41 GB once. Scope any cleanup to images this repo created, by ID.

`script/cibuild`'s main build is an untagged `docker build .`, so each run exports an unreferenced image (`naming to moby-dangling@sha256:...`). Because the check layer is cache-busted by `CHECK_EPOCH`, every invocation produces a genuinely new image ID, so these accumulate one per run rather than replacing each other. This got easier to hit when `make cibuild` landed (https://git.eeqj.de/sneak/lora.vegas/issues/34): the CI build is now a one-word command a developer will actually run locally, on a host whose docker storage is shared with other work. `script/lint` already avoids exactly this with `--output type=cacheonly`, so the two entrypoints disagree today. Found during review of https://git.eeqj.de/sneak/lora.vegas/pulls/41 and deliberately not fixed there — out of that issue's scope. ## Options 1. Tag the build, as `script/docker` already does via `script/projectname`, so each run replaces the previous image instead of orphaning it. Keeps an inspectable image. 2. `--output type=cacheonly`, matching `script/lint`. Cheapest, but leaves nothing to inspect or run — wrong if the point of `cibuild` is to produce the CI image. Recommendation: option 1. `cibuild` is a build, not just a gate, so it should leave exactly one current image rather than none. ## Definition of done - `script/cibuild` no longer accumulates dangling images; demonstrated by counting them across two consecutive runs, not by reasoning. - Whichever option is taken, the reason is stated in the script next to the flag, and the divergence from `script/lint` is either removed or explained. - The check layer still demonstrably executes — no warm-cache green. - `make check` green. ## Constraint Do **not** clean up existing dangling images with any global prune. This host's build cache is shared with other sessions and an unscoped prune has already destroyed 41 GB once. Scope any cleanup to images this repo created, by ID.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/lora.vegas#42