Request
Please set (or expose a way for us to set) a shorter BuildKit unused-layer retention for our installation:
- Target
keepDuration: 48–72h (today’s hardcoded default is 192h / 8 days)
- and/or a
keepBytes cap on unused layers
Repo: InnerlightSoftware/nexus (many Dockerfiles, sticky-disk cache-key per Dockerfile via setup-docker-builder@v2).
Why
We correctly cache lockfile-keyed pnpm install layers. Inevitable one-shot layers (anything whose parent is COPY . . / turbo prune output / turbo build / pnpm deploy) still accumulate ~GB per commit per touched image. With main moving ~30×/day and affected-image detection, a layer untouched for ~3 days is effectively dead — but native GC keeps it for 8 days.
We already:
- Shard per Dockerfile (
cache-key)
- Dropped the never-hit portal rematerialize install
- Serialized scheduler-api + scheduler-worker onto one key
Storage is still dominated by those one-shot layers under the 8-day window. There is no workflow input for GC after v2 removed max-cache-size-mb.
References
Happy to move this to the dashboard support channel if that’s preferred.
Request
Please set (or expose a way for us to set) a shorter BuildKit unused-layer retention for our installation:
keepDuration: 48–72h (today’s hardcoded default is192h/ 8 days)keepBytescap on unused layersRepo:
InnerlightSoftware/nexus(many Dockerfiles, sticky-diskcache-keyper Dockerfile viasetup-docker-builder@v2).Why
We correctly cache lockfile-keyed
pnpm installlayers. Inevitable one-shot layers (anything whose parent isCOPY . ./turbo pruneoutput /turbo build/pnpm deploy) still accumulate ~GB per commit per touched image. Withmainmoving ~30×/day and affected-image detection, a layer untouched for ~3 days is effectively dead — but native GC keeps it for 8 days.We already:
cache-key)Storage is still dominated by those one-shot layers under the 8-day window. There is no workflow input for GC after v2 removed
max-cache-size-mb.References
gcPolicy: [{ all: true, keepDuration: "192h0m0s" }](server can override viaGetStickyDisk)Happy to move this to the dashboard support channel if that’s preferred.