-
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
Multi-stage COPY --from uses wrong cache #1262
Comments
We've hit that too. Our workaround was to modify the Dockerfiles to ensure the "from IMAGE" is cache bust when needed |
Could you provide an example, please? |
I wonder if an even dirtier workaround could be to rename your stages in the Dockerfile for each Kaniko build. Obviously that'd be too much trouble and defeat the purpose, though. |
Hey folks, is there any plans to address this? |
+1 |
+1 Still happens to me on your latest release |
Hello, I know it's not easy to maintain a project like that, but is it possible to have an ETA on this issue ? Have a good day. |
We are running into the very same issue, described here #1348. |
Hello, After long hours of debugging pipelines, I've ended up with this hack to "parametrize" COPY command so it has a new hash every run: Dockerfile.template:
Build script:
|
Is anyone working on a fix to this? I assume |
I think we need to do something like also store the digest of the from image in the cache key. Edit: Actually we seem to maybe already do that, so not sure what the issue is. |
I reproduced the error with |
Any idea which patches solved it? I was having some similar issues so I removed my use of caching, but should test if it's resolved. |
No idea. If it helps with further kaniko development or some users are still encountering a variant of this problem with 1.8.0 I can offer to bisect my particular case. Otherwise let's just use 1.8.0. |
I tested my reproduction case and it works too! 🎉 I think we can close this. |
Actual behavior
We're using kaniko to build our images in a GitLab runner within OpenShift. When the first
COPY
expression in a Dockerfile is aCOPY --from
expression, the cache is used, even though a previous stage produced a layer which is different from the one in the cache.I created https://github.com/ronnn/kaniko-caching as a reference to reproduce the bug.
Also see: False-positive cache-hit on COPY --from #870
Expected behavior
We expect the date that is echoed to always be the date of the corresponding build image.
To Reproduce
Steps to reproduce the behavior:
This produces the following output. See how the date that should be copied from the second build image (Mon May 11 08:53:46 UTC 2020) is the one from the first build image instead (Mon May 11 08:52:10 UTC 2020). The third run without the cache works as expected.
If the
COPY
expressions inDockerfile_release
are switched (see commented lines) the cache is working as expected. We'll try to uses this as a workaround for now.Triage Notes for the Maintainers
--cache
flagThe text was updated successfully, but these errors were encountered: