The .dockerignore file also matches between stages

[michas2]

Actual behavior
The patterns in .dockerignore match not only in workdir but also when copying between stages.

Expected behavior
I expected kaniko to have the same semantics as in docker build.
The patterns should match only on initial import relative to /workdir/ not between stages relative to /.

To Reproduce

$ cat Dockerfile 
from busybox
run mkdir /foo/
run touch /foo/bar
run ls -l / /foo/

from busybox
copy --from=0 /foo/ /foo/
run ls -l / /foo/
$ cat .dockerignore 
/foo/
$ docker run --rm -v $PWD:/workspace gcr.io/kaniko-project/executor:v0.9.0 --no-push
[...]
INFO[0007] copy --from=0 /foo/ /foo/                    
INFO[0007] Taking snapshot of full filesystem...        
INFO[0007] Skipping paths under /kaniko, as it is a whitelisted directory 
INFO[0007] Skipping paths under /dev, as it is a whitelisted directory 
INFO[0007] Skipping paths under /proc, as it is a whitelisted directory 
INFO[0007] Skipping paths under /sys, as it is a whitelisted directory 
INFO[0007] Skipping paths under /workspace, as it is a whitelisted directory 
INFO[0008] No files were changed, appending empty layer to config. No layer added to image. 
INFO[0008] run ls -l / /foo/                            
INFO[0008] cmd: /bin/sh                                 
INFO[0008] args: [-c ls -l / /foo/]                     
ls: /foo/: No such file or directory

Trying the same with v0.7.0 or docker build works fine.

[MajorBreakfast]

I ran into the same issue. Here's my minimal test scenario

Dockerfile:

FROM alpine:3.9 AS intermediate

RUN cd /
RUN mkdir myDir
RUN echo "I am here!!!" > /myDir/shouldBeCopied.txt

FROM alpine:3.9

COPY --from=intermediate /myDir/shouldBeCopied.txt wasCopied.txt

RUN cat wasCopied.txt

Dockerignore:

# Each one prevents shouldBeCopied.txt from being copied (remove all these to make it work)
/myDir/shouldBeCopied.txt
/myDir
myDir

# Weirdly not a problem
shouldBeCopied.txt

docker run -v ${PWD}:/project gcr.io/kaniko-project/executor:debug-c8fabdf6e43b19f6a223f1d0b06e127d0774bd7e executor --context project --dockerfile ./project/Dockerfile --no-push

Expected output: Log message "I am here!!!" contained in the build log
Actual output:

INFO[0017] COPY --from=intermediate /myDir/shouldBeCopied.txt wasCopied.txt 
error building image: error building stage: copy failed: no source files specified

[heroic]

We got this issue today as well. node_modules from the first step would not get copied to the next as long as it was present in .dockerignore

[davidcurrie]

Hitting this too. Particularly problematic if, like me, your .dockerignore typically starts with a ** followed by a whitelist.

[leosunmo]

Hit the same issue as @heroic with node_modules not being copied between build steps.
As far as I can tell this seems like the common pattern for front-end builds that utilise multiple build steps (which is more and more common as you don't want all that initial build bloat in the final image) and the node_modules directory seems a common target to ignore. Unsure what the best workaround is for now but we've decided to remove .dockerignore completely and try to rely on Kaniko as much as possible.

[thewilli]

@leosunmo Unsure what the best workaround is for now but we've decided to remove .dockerignore completely and try to rely on Kaniko as much as possible.

For sure not the best workaround, but I went with using the executor:debug image to have a shell and then alter / remove the .dockerignore without any persistent changes to the repository in the corresponding CI step only.

[i-wilson]

I ended up getting around this the same way @thewilli

I'd love to actually help fix this, Is the logic simple between how docker cli handles this vs kaniko? I'll dig around but if someone could point me in the right direction I'd appreciate it.

[tejal29]

thanks all. i have a fix for this and will try to get this in by next release.

[niklasnatter]

that are great news - thanks a lot! @tejal29

[afirth]

@tejal29 is this fixed now? I noticed that .dockerignore doesn't seem to work at all in 0.16.0, but it's back in 0.18.0 - couldn't find anything in the release notes though

[tejal29]

@afirth no i have not merged the patch. i will get it in v0.19.0

[glen-84]

@tejal29 Did you forget about this? 😞

[mashail]

The issue is still exist in version 0.19.0!!

[eonicle]

Just hit that issue for a first time - pretty frustrating. If real fix is delayed, this should at least be mentioned somewhere in docs.

[tejal29]

Sorry folks, this got dropped. Fix here -> #1234