Open FFdhorkin opened 7 months ago
@tonistiigi do you know if there's a tracking issue for that in buildkit?
Just wasted a couple of hours on this one due to the misleading information. I was trying to diagnose a problem with an earlier line so wasn't concerned with the line that was reporting the failure ( I was going to fix that problem after I had sorted the problem in the earlier line).
So we definitely need a better error message to indicate what is going on.
I agree with @FFdhorkin suggestion of a message such as:
docker/for-win#9 SKIPPED: build expected to fail due to missing file (see below)
On mac is the same
this wastes so much time
Same issue. Wasted at least 2 hours on this unnecesarily.
Description
I was having an issue where a docker build seemed to be caching layers even when I had gone to extensive lengths (like
docker system prune -a
, and even doing a clean install of docker) to ensure that I was building from a clean state. Even when I used--no-cache
, it was saying layers were cached. This seemed very bizarre, and Google searches weren't being very helpful.Eventually, I decided that there was no way it was possibly cached, and figured out that the issue was because Docker was using some sort of lookahead logic, realizing that a later part of the build was going to fail, and fast-failing early. I don't have any issue with this behavior, but it was 100% not clear this was what was happening.
In my case, since the part that was failing was later in the Dockerfile and I was expecting a failure there (and just hadn't gotten to updating that part yet), I was ignoring the fact the build was failing and focused on trying to figure out why earlier layers were being cached when there was no way they should have been cached.
Commenting out that other part that I knew was broken suddenly caused previous parts of the Dockerfile to no longer claim to be cached.
Ultimately, this is more of a design bug than a code bug. It should absolutely not say
CACHED
unless it means it's actually cached - in this case, it should say SKIPPED or ABORTING something like that. Or just omit the skipped layers from the log, and jump right to the detected problem later in the Dockerfile.Reproduce
Here's a minimal example of what was triggering this behavior for me:
Dockerfile:
Expected behavior
if a step/layer is skipped because Docker realizes a file it's supposed to copy doesn't exist, it should indicate it's skipping steps, aborting the build, or just fully omit that section from the log.
docker version
docker info
Diagnostics ID
225DAB08-088F-4B5D-9122-FD010F1A0C06/20240125224854
Additional Info
Actual log:
Example of desired log (partial):
Alternatively: