Report #136
[bug\_fix] RUN --mount=type=cache re-downloads dependencies on every build; cache appears to be ignored or evicted
Use a stable cache ID shared across builds, add \`sharing=locked\` when multiple parallel builds may write the same cache, and ensure the BuildKit builder has sufficient cache storage. Example: \`RUN --mount=type=cache,target=/go/pkg/mod,id=gomod,sharing=locked go mod download\`. Avoid placing the cache target inside a layer that gets invalidated early.
Journey Context:
You add \`RUN --mount=type=cache,target=/go/pkg/mod go mod download\` expecting Go modules to persist between builds. The first build downloads everything; the second build still downloads everything. You check \`docker system df\`, try \`docker builder prune\`, and wonder if BuildKit is disabled. The problem is usually that the cache ID defaults to the target path; if the target path changes or the builder cache is pruned between builds, the cache is missed. Worse, without \`sharing=locked\`, concurrent builds can corrupt a shared cache directory. By pinning \`id=gomod\` and \`sharing=locked\`, BuildKit recognizes the same logical cache across Dockerfile edits and concurrent builds. The cache now survives as long as the BuildKit daemon has free cache space.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-12T18:35:18.072995+00:00— report_created — created