-
Notifications
You must be signed in to change notification settings - Fork 509
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
Bake: Cache of child target gets invalidated by COPY in parent #2144
Comments
I've confirmed this. Not so clear what might cause this. The issue is likely on buildkit side but let's keep it here for now, as the reproducer is with bake. |
A data point that if |
And in any case both the parent I've now tried with older versions of buildkit down to v0.7.2, but the problem stays. (Could not test with v0.5.1 anymore, because of a change in how cache files are stored) |
Passing a static image target to |
@tonistiigi how can I further debug this? If you say that its caused by buildkit, then I should be able to reproduce it with buildkit too. Do you have any hints on how to implement a minimal reproducer based on buildkit only? |
@flozzone the right way to reproduce in buildkit would probably be in an integration test. See https://github.com/moby/buildkit/blob/master/client/client_test.go, for the other tests, and https://github.com/moby/buildkit/blob/master/.github/CONTRIBUTING.md#run-the-unit--and-integration-tests for instructions on running them. To test if a layer is cached, the general way we do this is to read from Capturing the exact circumstances the bug happens under might be a bit tricky - you might need to read through buildx's bake code to make sure to do the same number of SolveOpts that bake does. |
I'm also facing this exact issue. The I've added my own steps to reproduce in https://github.com/kmontg/bake-cache-issue. This only seems to be a problem on the first build after a cache purge (even with a specified alternative cache backend). |
That seems to be really minimal @kmontg 👍 @jedevc I completely agree with you that a integration test would be the way to go for this issue here. But as you already described this can be bit tricky and I don't have the possibilities to dive into the codebase. I don't even know where to start with a buildkit based reproducer, since this issue involves chained builds and it's not really clear to me how to realize this in buildkit. I don't know why this issue has not yet attracted more attention, because buildkit advertises caching as an important feature "concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit". @jedevc , @tonistiigi do you have any suggestions on how to progress here? I will probably not be able to come up with an integration test, but @tonistiigi was able to reproduce this bug and confirmed it. Should we move this issue to buildkit repo, but still keep the bake based reproducer, preferably the one from @kmontg https://github.com/kmontg/bake-cache-issue |
This specific issue should be fixed with #2265 , but there is a more general issue that is causing it, tracked in moby/buildkit#4674 . |
Contributing guidelines
I've found a bug and checked that ...
Description
Building cached chained image with bake invalidates child layer caches if parent contains a COPY command. Running the example bake build a second time results in different image Ids for
image2
images (A
vsB
), even though first run cached layers forimage2
.COPY
line in1.Dockerfile
bothimage2
(A
andB
) are the same.image1
are always the sameSOURCE_DATE_EPOCH=1
has no impactBUILDX_NO_DEFAULT_ATTESTATIONS=1
has no impactBUILDX_GIT_INFO=0
has no impactmode=min
ormode=max
has no impactPossibly related to:
COPY
d file in parent image #1244Minimal reproducer
Reproducer: https://github.com/flozzone/docker-bake-invalidate-child-cache builds the above bake file twice using a common cache between runs
A
andB
:Usage:
./test.sh RUN_ID
A refers to the images built from first run
B refers to the images built from second run
Usage example:
Expected behaviour
The second build should output the same
image2
image Id as the first run.Actual behaviour
The second build outputs a different
image2
image Id than the previous run and layers for image2 are not re-used.Buildx version
github.com/docker/buildx v0.12.0 542e5d810e4a1a155684f5f3c5bd7e797632a12f
Other versions
Docker version 24.0.7, build afdd53b
github.com/docker/buildx v0.12.0 542e5d810e4a1a155684f5f3c5bd7e797632a12f
moby/buildkit:v0.12.3
docker-container
--debug
local
, no additional cache optionsDocker info
Builders list
Configuration
1.Dockerfile
test-copy.txt
2.Dockerfile
docker-bake.hcl
Build logs
The text was updated successfully, but these errors were encountered: