Conversation
github-actions
bot
added
area/dockerfile
area/testing
area/frontend
area/buildctl
labels
This adds support for the --automount flag as proposed in issue moby#2594. The flag allows users to specify mounts that are automatically applied to all RUN commands in a Dockerfile, without needing to modify the Dockerfile itself. This is useful for injecting: - Custom CA certificates for HTTPS interception proxies - Environment-specific build configurations - Other build-time mounts that should apply to all RUN steps Usage example: buildctl build --automount type=bind,source=ca.crt,target=/etc/ssl/certs/ca-certificates.crt Supported mount types: - bind: bind mounts from the build context - cache: persistent cache mounts - tmpfs: temporary filesystem mounts - secret: secret mounts - ssh: SSH agent socket mounts The implementation extracts mount conversion logic into a shared dispatchMount() function that is reused by both dispatchRunMounts (for RUN --mount=...) and dispatchAutomounts (for --automount). Closes moby#2594 Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Co-authored-by: NiklasRosenstein <1318438+NiklasRosenstein@users.noreply.github.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
… stages Co-authored-by: NiklasRosenstein <1318438+NiklasRosenstein@users.noreply.github.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Co-authored-by: NiklasRosenstein <1318438+NiklasRosenstein@users.noreply.github.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Co-authored-by: NiklasRosenstein <1318438+NiklasRosenstein@users.noreply.github.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
The automount feature was broken because ParseMount was called with a nil expander, which caused it to skip parsing all key-value pairs in the mount specification. This resulted in mount fields (type, id, target) never being set, causing "invalid mount target" errors. Fixed by providing a no-op expander function that returns values unchanged. Automounts should not support variable expansion anyway, as they are specified on the command line rather than in the Dockerfile. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
Add comprehensive integration tests for the --automount flag that automatically applies mounts to all RUN commands. Tests cover: - Basic secret/cache/bind/tmpfs automounts - Multiple RUN commands and multiple automounts - Coexistence with explicit RUN --mount directives - Multi-stage build support - Error handling for invalid specs and unsupported 'from' option Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
NiklasRosenstein
force-pushed
the
claude/add-automount-flag-sVgKO
branch
from
1eb771c to
0abfc16
Compare
|
|
||
| // filterValues extracts values from opt map where keys start with the given prefix. | ||
| // The values are returned as a slice, sorted by key to maintain stable ordering. | ||
| func filterValues(opt map[string]string, prefix string) []string { |
There was a problem hiding this comment.
This was introduced to ensure a stable order in which the mounts are applied. The thinking here is that one mount could overshadow another intentionally, and if applied in the wrong order, it would not function as intended.
Signed-off-by: Niklas Rosenstein <rosensteinniklas@gmail.com>
|
There are a lot of CI errors; I'll move this into draft until I've investigated them. |
|
I'm not sure this idea is a particularly good idea for inclusion into the default frontend. It makes reproducing the build more difficult because it relies on an outside CLI argument and also adds an implicit argument that changes every run command in the file without it being particularly obvious. The PR also has been open with failing tests for a couple of months now. I'm going to close it for now since it doesn't seem like there's been any activity on the pull request in quite awhile and I don't think it's likely that a maintainer is going to pick it up and try to carry the PR into a mergeable state. If this is something still desired for inclusion, let's make an issue to discuss the underlying problem and ways that it might be addressed. My first inclination is that this isn't the correct solution, but maybe there's something I'm missing in my understanding. |
@jsternberg Isn't this already true of build args and secrets? |
This PR adds and
--automountflag tobuildctl buildthat behaves semantically as if a corresponding implied--mountflag was specified on everyRUNcommand of a Dockerfile. This is based on an original suggestion by @rittneje in #2594.The primary use case from my PoV is to inject a custom SSL certificate chain at build time, which is usually a property of the environment in which the build takes place that one does not want to encode into the Dockerfile itself.
Example use:
I'm hoping that down the line we can expose the same flag to
docker buildx build.Disclaimer: This PR was assisted by Claude Code (writing) and GitHub Copilot (review). I've reviewed the contents and claim them to be adequate, but I have not contributed to a Go project before nor am I much familiar with the language. If the quality of the PR is not up to standards, I'm happy to take pointers and go back to the drawing board.