CopyIgnoredFile goes silent for all files when the .dockerignore contains any negated pattern

[saeedturk1969]

Contributing guidelines and issue reporting guide

• I've read the contributing guidelines and wholeheartedly agree. I've also read the issue reporting guide.

Well-formed report checklist

• I have found a bug that the documentation does not mention anything about my problem
• I have found a bug that there are no open or closed issues that are related to my problem
• I have provided version/information about my environment and done my best to provide a reproducer

Description of bug

Bug description

CopyIgnoredFile stops firing entirely once the .dockerignore contains any negated (!) pattern — including a negation for an unrelated directory, and including one naming a path that does not exist. The rule is not merely relaxed for the re-included path; it goes silent for every file in the build.

This looks like the false-negative left behind by the fixes for the false-positive reports #5884, #6512 and #6926, all of which involved negations. Those were right that the rule must not warn about a path a ! line brings back. The current behaviour appears to have gone further and suppressed the rule whenever a negation is present at all.

The practical consequence is worse than the rule simply not existing, because the suppression is introduced by the repair. A project that hits a genuine CopyIgnoredFile and fixes it the documented way — adding the ! exception — thereby disables the check for every file added afterwards, with nothing in the diff to say so, and the check keeps reporting Check complete, no warnings found.

That is not hypothetical. It happened to us twice in five days. The first occurrence was caught, fixed with a ! line, and a CI job was added around docker build --check to catch the next one. The second occurrence four days later produced a green check and a broken image on our main branch; nothing deployed for twelve hours.

Reproduction

$ mkdir -p sub && echo one > sub/a.txt && echo two > sub/b.txt && echo three > other.txt
$ printf 'FROM busybox\nCOPY sub/a.txt /\n' > Dockerfile

sub/a.txt is excluded in every case below and is never re-included, so the rule should fire every time.

.dockerignore	docker build --check
sub/	CopyIgnoredFile fires
sub/ !sub/b.txt	silent
sub/ !other.txt — negation for a different directory	silent
sub/ !nope/missing.txt — negation naming a nonexistent path	silent
!sub/b.txt sub/ — negation before the exclusion	silent

The third and fourth rows are the ones that suggest this is broader than the intended relaxation: neither negation can affect whether sub/a.txt is in the context, and one of them names nothing at all.

The build itself fails as expected in all five cases, so the context filtering is correct and only the lint rule is affected:

ERROR: failed to compute cache key: failed to calculate checksum of ref ...: "/sub/a.txt": not found

Expected behaviour

A negation should suppress the warning for the paths it re-includes, and leave the rule active for everything else. A negation for an unrelated path, or for a path that does not exist, should not affect the rule at all.

Version information

Docker version:   29.6.2
buildx:           v0.35.0 (a319e5b15052cf6557ceb666eb8ff6e32380b782)
BuildKit version: v0.31.2
Driver:           docker
Platform:         linux/amd64

Behaviour is identical with and without --build-arg BUILDKIT_DOCKERFILE_CHECK=error=true; the rule does not fire, so there is nothing to escalate to an error.

Note on severity

Not urgent for us — we replaced the check with our own resolution of COPY sources against the effective ignore file. Filing because the failure mode is quiet, and because a rule that a correct repair switches off is likely to be affecting other projects that have no reason to suspect it.