-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No-cache not working for--mount=type=cache
when mode
is specified
#5305
Comments
Seems related to the issue I was trying in this PR in BuildKit; And this comment; #4936 (comment) - not sure if we can apply a similar hack in |
Ignore, see next commentFWIW, I could not seem to reproduce any difference from running it twice, but it is unclear if the reproduction is meant to have the failure? Adding Build output
No difference with That said I was not able to reproduce the BuildKit
A bit more clarity on the expectation here would be helpful. You run the build with |
TL;DR:
So @jackblackevo observed:
ReproductionHere is a reliable reproduction example that isn't dependent upon external state (since that nodejs build example was failing). FROM alpine
RUN --mount=type=cache,target=/example,mode=773 <<HEREDOC
echo "Octal permissions are: $(stat -c %a /example)"
ls /example
touch /example/i-will-persist-if-mode-is-set
HEREDOC
# Sanity check, that file should only persist here and not above on subsequent builds with `--no-cache`:
RUN --mount=type=cache,target=/example,mode=773 \
ls /example # Add --builder arg as described below to observe difference in build outputs
docker buildx build --load --no-cache --progress plain . You will observe with the above:
More interestingly though, regardless of The build output will indicate the cache mount persistence with this additional info:
#4936 references a line that uses all these options as inputs, which might explain the relation to those options?:
Presumably a bug? (I would actually like this flexibility to retain cache mounts with Each builder instance maintains their own cache mount. The mode contributes to an implicit cache key, but it is unclear why it breaks I assume this inconsistency is related to the TBH I would prefer this distinction to not clear cache mounts when I only want to do a clean image build, especially since cache mounts can be shared across Dockerfile builds, so I like this behaviour. A separate control to temporarily ignore cache mounts would make more sense than discarding them (unexpected for me when I first encountered that). |
Sorry, my reproduction method was mixed with npm-related information, which prevented the issue from being presented simply. I referred to your Dockerfile and made some modifications to demonstrate the problem I encountered. ReproduceFROM alpine
RUN --mount=type=cache,target=/example <<HEREDOC
echo "Octal permissions are: $(stat -c %a /example)"
ls /example # The files should be listed during the second build.
touch /example/i-should-persist
HEREDOC
RUN --mount=type=cache,target=/example \
ls /example First run
|
Thanks for putting together the expected vs actual outcomes 👍 I have only seen Inspecting the cache mounts we can observe that how the ones without # List available cache mounts:
docker builder du --builder default --filter 'type=exec.cachemount' --verbose While you can remove any of those via In I suppose the outcome depends on what the general expectation of |
@thaJeztah I assume this is related to host umask leaking to files created by dockerd. I think it should use the host umask like buildkitd. |
That is a separate issue with The main issue here is with the mount options
Also note, any change in those options values will create a new cache mount (unclear if that is a bug), even when the |
@polarathene Expected behavior is that the cache mounts that would be used by the build are removed if |
Ok thanks :) The behaviour is still inconsistent when those mount options are present, along with the Below is for reference, regarding related concerns on the topic. From the PR description:
From associated issue it resolves: docker/buildx#109 (comment)
From related issue: moby/moby#38255 (comment)
That corruption concern is still expressed in 2024 as there is no proper support for querying the appropriate cache mount to prune. As stated Running a build with
|
That is not the behavior of |
Where can I find the relevant documentation? I was reading about the |
I understand that, hence the mention of the Presently |
--mount=type=cache
when mode
is not explicitly specified--mount=type=cache
when mode
is specified
👋 @polarathene . We've transferred to the buildkit repo and will be tracking this issue for now. Thanks! #5306 opened. |
Description
I've encountered an inconsistent behavior when using
--mount=type=cache
in Dockerfile. When themode
parameter is not explicitly specified, the cache mount doesn't seem to work correctly, despite the documentation stating that the defaultmode
is0755
. However, when I explicitly use--mount=type=cache,mode=0755
, it works normally.Reproduce
npm install hello
docker build --progress=plain --no-cache .
twiceExpected behavior
The cache mount should work correctly with the default
mode
(0755
), as per the documentation.It should work the same as:
docker version
docker info
Additional Info
No response
The text was updated successfully, but these errors were encountered: