Closed tetienne-zenchef closed 2 days ago
Yeah, we ran into this same issue, I wonder if this new buildkit image is more strict on COPY command syntax? It seems a potential fix
is to ensure that the COPY command ends in a trailing slash
Indeed, changing to COPY --link readme ./
seems to be the workaround.
018155fa68e3ab267588f4f1735532bcfb7f02aa is the first bad commit
commit 018155fa68e3ab267588f4f1735532bcfb7f02aa
Author: Anthony Nandaa <profnandaa@gmail.com>
Date: Fri Apr 5 14:32:58 2024 +0300
fix: use unix path separator since path already normalized
In the case for Windows, this line at
frontend/dockerfile/dockerfile2llb/convert.go#L1142
```go
dest += string(filepath.Separator)
was adding the `\\` to a path that is already normalized
to unix-format, hence ending up with dest paths like
`/\\` for `C:\\` and `/test\\` for `C:\\test\\`.
the src paths are well normalized too at ~L1290.
This change removes the block of code and instead
does the "/" appending using the keepSlash logic
that is in system.NormalizePath called in
pathRelativeToWorkingDir() function before.
fixes #4696
Signed-off-by: Anthony Nandaa <profnandaa@gmail.com>
frontend/dockerfile/dockerfile2llb/convert.go | 8 ++------ solver/llbsolver/file/backend.go | 2 +- 2 files changed, 3 insertions(+), 7 deletions(-)
https://github.com/moby/buildkit/pull/4825
@profnandaa @gabriel-samfira
@tonistiigi -- will take a look. it should be more forgiving for such a case.
Fix raised, but I've also opened an issue to add a few test cases on our integration tests to cover these path scenarios.
Hi,
we face this issue with v0.14.1 (and 0.14.0), but was OK with v0.13.2.
To reproduce
When doing the copy without
--link
, build is OK.