-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
layer created implicitly by WORKDIR is not cached #3340
Comments
this is the underlying cause of #3246 |
problem is here https://github.com/GoogleContainerTools/kaniko/blob/main/pkg/commands/workdir.go#L74 |
Just ran into this issue. Would love to see 3341 merged! |
Ran into the same issue. 3341 is not merged yet. Is there any other workaround ? |
you can ensure that the workdir exists prior to running the command, not nice but not terrible either RUN mkdir /app
WORKDIR /app |
Actual behavior
When
WORKDIR
is called on a non-existent directory, kaniko is kind enough to create that directory for you, resulting in a layer being added. However, kaniko does not cache that layer, which means that on every invocation a completely new image is emitted from that point onwards. Inside the same stage this is non-obvious as caching mechanism still pulls, so you get a 100% cache hitrate thereafter, but the image is completely new. In multistage builds or builds that depend on the newly emitted image, this is catastrophic, as they do consider the entire image's sha when determining whether a cache is hit or not, so this will invalidate the entire cache.Workaround is simple but silly, we just need to make sure that the directory exists before calling
WORKDIR
Expected behavior
When
WORKDIR
is called on a non-existent directory, that directory is implicitly created and the resulting layer is pushed into cache.To Reproduce
run this build multiple times, with cache, and observe that the layers change every time
Triage Notes for the Maintainers
--cache
flagThe text was updated successfully, but these errors were encountered: