GoogleContainerTools / kaniko

Build Container Images In Kubernetes
Apache License 2.0
14.88k stars 1.44k forks source link

Weird behavior with `--context` and docker WORKDIR #2021

Open zzh8829 opened 2 years ago

zzh8829 commented 2 years ago

Actual behavior

image

Dockerfile content

FROM ubuntu
WORKDIR /workspace
RUN ls -al

Run this build command

docker run --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor --dockerfile Dockerfile --context /workspace --no-push
INFO[0000] Retrieving image manifest ubuntu             
INFO[0000] Retrieving image ubuntu from registry index.docker.io 
INFO[0001] Built cross stage deps: map[]                
INFO[0001] Retrieving image manifest ubuntu             
INFO[0001] Returning cached image manifest              
INFO[0001] Executing 0 build triggers                   
INFO[0001] Unpacking rootfs as cmd RUN ls -al requires it. 
INFO[0004] WORKDIR /workspace                           
INFO[0004] cmd: workdir                                 
INFO[0004] Changed working directory to /workspace      
INFO[0004] No files changed in this command, skipping snapshotting. 
INFO[0004] RUN ls -al                                   
INFO[0004] Taking snapshot of full filesystem...        
INFO[0005] cmd: /bin/sh                                 
INFO[0005] args: [-c ls -al]                            
INFO[0005] Running: [/bin/sh -c ls -al]                 
total 8
drwxr-xr-x 4 root root  128 Mar 30 00:59 .
drwxr-xr-x 1 root root 4096 Mar 30 01:02 ..
-rw-r--r-- 1 root root   45 Mar 30 00:59 Dockerfile
drwxr-xr-x 3 root root   96 Mar 30 00:58 folder
INFO[0005] Taking snapshot of full filesystem...   

Expected behavior I'd expect ls should have no output since we haven't copied any files into the docker build yet

from my investigation this bug happens when dockerfile uses WORKDIR to cd into the same directory as the local --context directory

this behaves as intended if we mount $(pwd) to /workspace2 or use WORKDIR /workspace2 in dockerfile

I think this is a pretty serious bug because I definitely didn't expect kaniko's context to be copied into docker build process at all and there was nothing in the doc that explained this behavior.

Triage Notes for the Maintainers

Description Yes/No
Please check if this a new feature you are proposing
  • - [ ]
Please check if the build works in docker but not in kaniko
  • - [x]
Please check if this error is seen when you use --cache flag
  • - [ ]
Please check if your dockerfile is a multistage dockerfile
  • - [ ]
achendev commented 2 years ago

Thanks a lot for your investigation, it helped for me https://github.com/GoogleContainerTools/kaniko/issues/2049

zanechua commented 1 year ago

@aaron-prindle

Is this officially considered a bug?

If this is fixed and the directory is no longer mounted, is there a way for us to allow kaniko to mount a specific directory?

Would that just be using volume mounts?