Allow controlling cache mounts storage location
related https://github.com/moby/moby/issues/14080 Allowing exporting contents of the `type=cache` mounts have been asked many times in different repositories and slack. https://github.com/moby/buildkit/issues/1474 https://github.com/docker/buildx/issues/244 Regular remote instruction cache does not work for cache mounts that are not tracked by cache key and are just a location on disk that can be shared by multiple builds. Currently, the best approach to maintain this cache between nodes is to do it as part of the build. https://github.com/docker/buildx/issues/244#issuecomment-602750160 I don't think we should try to combine cache mounts with the remote cache backends. Usually, cache mounts are for throwaway cache and restoring it would take a similar time to just recreating it. What we could do is to allow users to control where the cache location is on disk, in case it is not on top of the snapshots. We can introduce a cache mount backend concept behind a go interface that different implementation can implement. Eg. for a Dockerfile like ``` RUN --mount=type=cache,target=/root/.cache,id=gocache go build ... ``` you could invoke a build with ``` docker build --cache-mount id=gocache,type=volume,volume=myvolume . ``` In that case, the cache could use a Docker volume as a backend. I guess good drivers would be volume in Docker and bind mount from the host for non-docker. If no `--cache-mount` is specified, the usual snapshotter-based location is used. From the sec
Posted by tonistiigi on May 27, 2020, 11:43 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.3,500 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
Allow controlling cache mounts storage location
related https://github.com/moby/moby/issues/14080 Allowing exporting contents of the `type=cache` mounts have been asked many times in different repositories and slack. https://github.com/moby/buildkit/issues/1474 https://github.com/docker/buildx/issues/244 Regular remote instruction cache does not work for cache mounts that are not tracked by cache key and are just a location on disk that can be shared by multiple builds. Currently, the best approach to maintain this cache between nodes is to do it as part of the build. https://github.com/docker/buildx/issues/244#issuecomment-602750160 I don't think we should try to combine cache mounts with the remote cache backends. Usually, cache mounts are for throwaway cache and restoring it would take a similar time to just recreating it. What we could do is to allow users to control where the cache location is on disk, in case it is not on top of the snapshots. We can introduce a cache mount backend concept behind a go interface that different implementation can implement. Eg. for a Dockerfile like ``` RUN --mount=type=cache,target=/root/.cache,id=gocache go build ... ``` you could invoke a build with ``` docker build --cache-mount id=gocache,type=volume,volume=myvolume . ``` In that case, the cache could use a Docker volume as a backend. I guess good drivers would be volume in Docker and bind mount from the host for non-docker. If no `--cache-mount` is specified, the usual snapshotter-based location is used. From the sec
Comments (0)
No comments yet. Start the discussion.