Open paisleyrob opened 4 years ago
Altered issue description to use scratch
instead of alpine
image.
@paisleyrob I created the same context from outside the container, and ran kaniko
docker run --rm -it \
--volume $HOME/ctxt:/build \
gcr.io/kaniko-project/executor:debug- v0.19.0@sha256:0d0e34396f47ec6d5fd75aebb9772147a78d96ed2bbb16ec892bd178efdc8307
--oci-layout-path /container \
--reproducible \
--no-push \
--context=/build
where my /ctxt directory contained your Dockerfile and "empty". The build successfully finishes. Generally, this is the recommended way to run Kaniko within a docker.
Please let me know if the issue can be closed.
@paisleyrob I created the same context from outside the container, and ran kaniko
docker run --rm -it \ --volume $HOME/ctxt:/build \ gcr.io/kaniko-project/executor:debug- v0.19.0@sha256:0d0e34396f47ec6d5fd75aebb9772147a78d96ed2bbb16ec892bd178efdc8307 --oci-layout-path /container \ --reproducible \ --no-push \ --context=/build
where my /ctxt directory contained your Dockerfile and "empty". The build successfully finishes. Generally, this is the recommended way to run Kaniko within a docker.
Please let me know if the issue can be closed.
I had to edit your command a little as follow to make it work:
docker run --rm -it \
--volume "$(pwd)"/docker:/build \
gcr.io/kaniko-project/executor:debug-v0.19.0@sha256:0d0e34396f47ec6d5fd75aebb9772147a78d96ed2bbb16ec892bd178efdc8307 \
--oci-layout-path /container \
--reproducible \
--no-push \
--context=/build
INFO[0000] Resolved base name scratch to scratch
INFO[0000] Resolved base name scratch to scratch
INFO[0000] Resolved base name scratch to scratch
INFO[0000] Resolved base name scratch to scratch
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Taking snapshot of full filesystem...
INFO[0000] Resolving paths
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
INFO[0000] Taking snapshot of full filesystem...
INFO[0000] Resolving paths
INFO[0000] COPY empty /
INFO[0000] Resolving paths
INFO[0000] Taking snapshot of files...
INFO[0000] Skipping push to container registry due to --no-push flag
Which worked.
I'm not comfortable closing this issue as I'm using this in a GitLab Runner environment, so I need it work from the kaniko debug image's shell, which it doesn't.
Updated to 0.21.0's output with verification this is still an issue.
Issue still persists with v1.2.0:
docker run -it --rm --entrypoint=/busybox/sh gcr.io/kaniko-project/executor:debug-v1.2.0@sha256:53d235fa995003bd43026d3463e8e43d654445816cca9135966615edacf3e0b6
/ # mkdir docker
/ # touch docker/empty
/ # cat > docker/Dockerfile << EOF
> FROM scratch
> FROM scratch
> COPY empty /
> EOF
/ # /kaniko/executor --context /docker --no-push --oci-layout-path /container --reproducible
INFO[0000] No base image, nothing to extract
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /docker/empty: lstat /docker/empty: no such file or directory
we saw the same issue with 1.2.0 here is our log
2020-10-23T22:00:12.540764648Z [36mINFO[0m[0026] Unpacking rootfs as cmd COPY --from=builder /app /user/local/app/app requires it.
2020-10-23T22:00:12.748595053Z error building image: error building stage: failed to execute command: resolving src: failed to get fileinfo for /kaniko/0/go/src/app: lstat /kaniko/0/go/src/app: no such file or directory
2020-10-23T22:00:12.748596567Z [36mINFO[0m[0026] COPY --from=builder ./app /user/local/app/app
the command we are running
Any updates on this? Still encountering this with the latest executor:debug
Any updates on this? Still encountering this with the latest
executor:debug
I mistook this for a request to see if it's still encountered on the latest and I came here to confirm, yes it's still a problem. v1.3.0
doesn't work either:
$ docker run --entrypoint /busybox/sh --interactive --tty --rm gcr.io/kaniko-project/executor:v1.3.0-debug@sha256:473d6dfb011c69f32192e668d86a47c0235791e7e857c870ad70c5e86ec07e8c
/ # mkdir docker
/ # touch docker/empty
/ # cat > docker/Dockerfile << EOF
> FROM scratch
> FROM scratch
> COPY empty /
> EOF
/ # /kaniko/executor --context /docker --no-push --oci-layout-path /container --reproducible
INFO[0000] No base image, nothing to extract
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /docker/empty: lstat /docker/empty: no such file or directory
I had a quick play, and:
The name of the directory doesn't matter.
If I use the same reproduction, but with /docker
mounted as a volume, it no longer fails.
If I use the same reproduction, but with /docker/test
, the /docker
directory is deleted:
> docker run --rm -it --entrypoint /busybox/sh gcr.io/kaniko-project/executor:debug
/ # ls
busybox dev etc kaniko proc sys
/ # mkdir -p /docker/test
/ # cd /docker/test/
/docker/test # touch empty
/docker/test # cat > Dockerfile <<EOF
> FROM scratch
> FROM scratch
> COPY empty /
> EOF
/docker/test # cd ..
/docker # /kaniko/executor --oci-layout-path /container --reproducible --no-push --context=/docker/test
INFO[0000] No base image, nothing to extract
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /docker/test/empty: lstat /docker/test/empty: no such file or directory
sh: getcwd: No such file or directory
(unknown) # pwd
/docker
sh: getcwd: No such file or directory
(unknown) # cd /
/ # ls
busybox dev etc kaniko proc sys
If my context is a subdirectory of a volume mount, the failure does not happen either.
> docker run --rm -it --entrypoint /busybox/sh --volume tmvol:/docker gcr.io/kaniko-project/executor:debug
/ # ls /
busybox dev docker etc kaniko proc sys
/ # ls /docker
/ # cd docker
/docker # mkdir test
/docker # cd test
/docker/test # touch empty
/docker/test # cat > Dockerfile <<EOF
> FROM scratch
> FROM scratch
> COPY empty /
> EOF
/docker/test # cd ..
/docker # ls
test
/docker # /kaniko/executor --oci-layout-path /container --reproducible --no-push --context=/docker/test
INFO[0000] No base image, nothing to extract
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
INFO[0000] COPY empty /
INFO[0000] Taking snapshot of files...
INFO[0000] Skipping push to container registry due to --no-push flag
/docker # ls test
Dockerfile empty
So I suspect this is not to do with the use of --entrypoint
, but relates to something Kaniko is doing with mount-point detection, that causes the "Deleting filesystem..." step to accidentally delete the directory in the root that contains the context, if it's not under a mount-point. Presumably there's code around that is walking up the tree to find a mount-point, but which doesn't correctly handle the case of "the mount point was /
".
The only relevant differences in the trace logs are around the mount-point lists, and I think debug logs would have shown them.
Working case:
DEBU[0000] Mounted directories: [{/kaniko false} {/etc/mtab false} {/tmp/apt-key-gpghome true} {/var/run false} {/proc false} {/dev false} {/dev/pts false} {/sys false} {/sys/fs/cgroup false} {/sys/fs/cgroup/cpuset false} {/sys/fs/cgroup/cpu false} {/sys/fs/cgroup/cpuacct false} {/sys/fs/cgroup/blkio false} {/sys/fs/cgroup/memory false} {/sys/fs/cgroup/devices false} {/sys/fs/cgroup/freezer false} {/sys/fs/cgroup/net_cls false} {/sys/fs/cgroup/perf_event false} {/sys/fs/cgroup/net_prio false} {/sys/fs/cgroup/hugetlb false} {/sys/fs/cgroup/pids false} {/sys/fs/cgroup/rdma false} {/sys/fs/cgroup/systemd false} {/dev/mqueue false} {/dev/shm false} {/busybox false} {/docker false} {/etc/resolv.conf false} {/etc/hostname false} {/etc/hosts false} {/dev/console false} {/proc/bus false} {/proc/fs false} {/proc/irq false} {/proc/sys false} {/proc/acpi false} {/proc/kcore false} {/proc/keys false} {/proc/timer_list false} {/proc/sched_debug false} {/sys/firmware false}]
Failure case:
DEBU[0000] Mounted directories: [{/kaniko false} {/etc/mtab false} {/tmp/apt-key-gpghome true} {/var/run false} {/proc false} {/dev false} {/dev/pts false} {/sys false} {/sys/fs/cgroup false} {/sys/fs/cgroup/cpuset false} {/sys/fs/cgroup/cpu false} {/sys/fs/cgroup/cpuacct false} {/sys/fs/cgroup/blkio false} {/sys/fs/cgroup/memory false} {/sys/fs/cgroup/devices false} {/sys/fs/cgroup/freezer false} {/sys/fs/cgroup/net_cls false} {/sys/fs/cgroup/perf_event false} {/sys/fs/cgroup/net_prio false} {/sys/fs/cgroup/hugetlb false} {/sys/fs/cgroup/pids false} {/sys/fs/cgroup/rdma false} {/sys/fs/cgroup/systemd false} {/dev/mqueue false} {/dev/shm false} {/busybox false} {/etc/resolv.conf false} {/etc/hostname false} {/etc/hosts false} {/dev/console false} {/proc/bus false} {/proc/fs false} {/proc/irq false} {/proc/sys false} {/proc/acpi false} {/proc/kcore false} {/proc/keys false} {/proc/timer_list false} {/proc/sched_debug false} {/sys/firmware false}]
The difference is the presence of {/docker false}
(that bool
is PrefixMatchOnly
).
This is the bug: DeleteFilesystem
appears to be designed to delete everything from the filesystem that isn't in the ignore list. And the ignore list is built from mountpoints plus some defaults. Annoyingly, DeleteFilesystem
is missing a debug log in the relevant branch, otherwise this would be very visible in the debug logs.
So I suspect a fix would be to automatically add the context directory to the ignore list. A build-from-git must already do this, or it pulls the context into an existing ignored directory (the latter is probably the case).
A workaround might be to bind-mount the context to itself before populating it, but I couldn't get that to work, trivially.
> docker run --rm -it --entrypoint /busybox/sh gcr.io/kaniko-project/executor:debug
/ # mkdir /docker
/ # mount -o bind /docker /docker
mount: permission denied (are you root?)
On the other hand, now that I know that Kaniko treats its own root as the image root, the following pathological feature works:
Given C:\Users\paulh\kantmp\docker\Dockerfile:
FROM scratch
RUN ["/kaniko/executor", "--help"]
> docker run --rm -it --volume C:\Users\paulh\kantmp\docker:/docker gcr.io/kaniko-project/executor:debug --oci-layout-path /container --reproducible --no-push --context=/docker
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Unpacking rootfs as cmd RUN ["/kaniko/executor", "--help"] requires it.
INFO[0000] RUN ["/kaniko/executor", "--help"]
INFO[0000] Taking snapshot of full filesystem...
INFO[0000] cmd: /kaniko/executor
INFO[0000] args: [--help]
INFO[0000] Running: [/kaniko/executor --help]
Usage:
executor [flags]
executor [command]
Available Commands:
help Help about any command
version Print the version number of kaniko
Flags:
--build-arg multi-arg type This flag allows you to pass in ARG values at build time. Set it repeatedly for multiple values.
--cache Use cache when building image
--cache-dir string Specify a local directory to use as a cache. (default "/cache")
--cache-repo string Specify a repository to use as a cache, otherwise one will be inferred from the destination provided
--cache-ttl duration Cache timeout in hours. Defaults to two weeks. (default 336h0m0s)
--cleanup Clean the filesystem at the end
-c, --context string Path to the dockerfile build context. (default "/workspace/")
--context-sub-path string Sub path within the given context.
-d, --destination multi-arg type Registry the final image should be pushed to. Set it repeatedly for multiple destinations.
--digest-file string Specify a file to save the digest of the built image to.
-f, --dockerfile string Path to the dockerfile to be built. (default "Dockerfile")
--force Force building outside of a container
--git gitoptions Branch to clone if build context is a git repository (default branch=,single-branch=false,recurse-submodules=false)
-h, --help help for executor
--image-name-with-digest-file string Specify a file to save the image name w/ digest of the built image to.
--insecure Push to insecure registry using plain HTTP
--insecure-pull Pull from insecure registry using plain HTTP
--insecure-registry multi-arg type Insecure registry using plain HTTP to push and pull. Set it repeatedly for multiple registries.
--label multi-arg type Set metadata for an image. Set it repeatedly for multiple labels.
--log-format string Log format (text, color, json) (default "color")
--log-timestamp Timestamp in log output
--no-push Do not push the image to the registry
--oci-layout-path string Path to save the OCI image layout of the built image.
--registry-certificate key-value-arg type Use the provided certificate for TLS communication with the given registry. Expected format is 'my.registry.url=/path/to/the/server/certificate'.
--registry-mirror string Registry mirror to use has pull-through cache instead of docker.io.
--reproducible Strip timestamps out of the image to make it reproducible
--single-snapshot Take a single snapshot at the end of the build.
--skip-tls-verify Push to insecure registry ignoring TLS verify
--skip-tls-verify-pull Pull from insecure registry ignoring TLS verify
--skip-tls-verify-registry multi-arg type Insecure registry ignoring TLS verify to push and pull. Set it repeatedly for multiple registries.
--skip-unused-stages Build only used stages if defined to true. Otherwise it builds by default all stages, even the unnecessaries ones until it reaches the target stage / end of Dockerfile
--snapshotMode string Change the file attributes inspected during snapshotting (default "full")
--tarPath string Path to save the image in as a tarball instead of pushing
--target string Set the target build stage to build
--use-new-run Use the experimental run implementation for detecting changes without requiring file system snapshots.
-v, --verbosity string Log level (trace, debug, info, warn, error, fatal, panic) (default "info")
--whitelist-var-run Ignore /var/run directory when taking image snapshot. Set it to false to preserve /var/run/ in destination image. (Default true). (default true)
Use "executor [command] --help" for more information about a command.
INFO[0000] Taking snapshot of full filesystem...
INFO[0000] No files were changed, appending empty layer to config. No layer added to image.
INFO[0000] Skipping push to container registry due to --no-push flag
Umm... Gosh. Turns out this last thing is already logged as #1553.
args:
- "--dockerfile=Dockerfile"
- "--context=dir://./"
Worked for me
Minor tweaks as WORKDIR
now seems to be /workspace
but this issue still exists with v.1.7.0
:
$ docker run --entrypoint /busybox/sh --interactive --tty --rm gcr.io/kaniko-project/executor:v1.7.0-debug@sha256:88dacc7ea3f5c04709eae96776693c717869405364b19d6e78850fe54c63c6a2
/workspace # mkdir docker
/workspace # touch docker/empty
/workspace # cat >docker/Dockerfile <<'EOF'
> FROM scratch
> FROM scratch
> COPY empty /
> EOF
/workspace # /kaniko/executor --context ./docker --dockerfile Dockerfile --no-push --oci-layout-path ./container --reproducible
INFO[0000] No base image, nothing to extract
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /workspace/docker/empty: lstat /workspace/docker/empty: no such file or directory
sh: getcwd: No such file or directory
(unknown) #
The above comment from @TBBle appears to pinpoint underlying issue.
@paisleyrob @TBBle thanks for digging into this.
Unfortunately this project is pretty short-staffed, so if you can find where in the code this is going wrong, or a recent commit that made it go wrong, that would be very helpful. I don't think there's anybody coming to save us here but us.
I'm not personally very familiar with the code, but I'd be happy to chat over Slack or video chat if you want to dig in together and throw around ideas.
This issue still exists in v1.9.1
:
$ docker run --entrypoint /busybox/sh --interactive --tty --rm gcr.io/kaniko-project/executor:v1.9.1-debug@ac169723b2076f9d5804f4bc05c98397e286da6fdcdd5a09fdc179f06ccb3be1
/workspace # mkdir docker
/workspace # touch docker/empty
/workspace # cat >docker/Dockerfile <<'EOF'
> FROM scratch
> FROM scratch
> COPY empty /
> EOF
/workspace # /kaniko/executor --context ./docker --dockerfile Dockerfile --no-push --oci-layout-path ./container --reproducible
INFO[0000] No base image, nothing to extract
INFO[0000] No base image, nothing to extract
INFO[0000] Built cross stage deps: map[]
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Building stage 'scratch' [idx: '0', base-idx: '-1']
INFO[0000] Skipping unpacking as no commands require it.
INFO[0000] Deleting filesystem...
INFO[0000] No base image, nothing to extract
INFO[0000] Executing 0 build triggers
INFO[0000] Building stage 'scratch' [idx: '1', base-idx: '-1']
INFO[0000] Unpacking rootfs as cmd COPY empty / requires it.
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /workspace/docker/empty: lstat /workspace/docker/empty: no such file or directory
sh: getcwd: No such file or directory
(unknown) #
I just ran into a very similar-sounding issue: I'm trying to COPY --from=previous_stage $CI_PROJECT_DIR/some_folder $CI_PROJECT_DIR/some_folder
in a Dockerfile built with Kaniko in Gitlab CI, where some_folder
is either a Python .venv
folder or an npm node_modules
folder and $CI_PROJECT_DIR
has been set to the same value as Gitlab's predefined variable of the same name (i.e. /builds/path/to/my/project
). This yields
error building image: error building stage: failed to execute command: resolving src: failed to get fileinfo for /kaniko/2/builds/builds/path/to/my/project/.venv: lstat /kaniko/2/builds/path/to/my/project/.venv: no such file or directory
(Meanwhile, building in Docker works fine.)
This did not happen before when my .venv
/ node_modules
folder was under a different path (/workdir
) in the previous stage and also got COPY
'ed to /workdir/.venv
, so given that $CI_PROJECT_DIR
is somewhat special in Gitlab CI, there seems to be some interaction between Kaniko and Gitlab CI going on here?
People have complained about similar issues here:
EDIT: It seems I have found a workaround: If in previous stages I use a source folder different from $CI_PROJECT_DIR
, then Kaniko will happily COPY --from=previous_stage $NEW_SOURCE_FOLDER/some_folder $CI_PROJECT_DIR/some_folder
. So, using $CI_PROJECT_DIR
as destination folder of the COPY
operation is okay, but using it as the source folder causes trouble for some reason.
Hi @codethief,
I'm running into a similar error. Could you share the relevant parts from your gitlab-ci yaml file and the Dockerfile that now works for you? That would be awesome!
My code and error:
kaniko:
stage: test
variables:
FARGATE_TASK_DEFINITION: "gitlab-runner-kaniko-v0"
REPO: ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${REPO_NAME}
extends: [.assume_role]
script:
- echo "creating docker config for ecr"
- mkdir -p /root/.docker
- echo '{"credsStore":"ecr-login"}' > /root/.docker/config.json
- export PATH=$PATH:/kaniko
# Source the AWS env vars to retrieve credentials use to push image to ECR
- source /etc/profile.d/set-aws-env-vars.sh
# build and push image
- /kaniko/executor --context $ENTRYPOINT --dockerfile $ENTRYPOINT/Dockerfile --destination $REPO:$IMAGE_TAG --ignore-path=/var/mail --ignore-path=/var/spool/mail
parallel:
matrix:
- ENTRYPOINT: "$CI_PROJECT_DIR/lib/gitlab_runner_task/images/kaniko_image"
IMAGE_TAG: kaniko-$CI_COMMIT_SHORT_SHA
ARG TARGETPLATFORM=linux/amd64
FROM --platform=${TARGETPLATFORM} gcr.io/kaniko-project/executor:v1.20.0 AS kaniko
FROM --platform=${TARGETPLATFORM} debian:bookworm
COPY --from=kaniko /kaniko/executor /kaniko/
COPY --from=kaniko /kaniko/docker-credential-gcr /kaniko/
COPY --from=kaniko /kaniko/docker-credential-ecr-login /kaniko/
COPY --from=kaniko /kaniko/docker-credential-acr-env /kaniko/
...
COPY docker-entrypoint.sh /usr/local/bin/
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /opt/gitlab-runner/builds/.../gitlab_runner_task/images/kaniko_image: lstat /opt/gitlab-runner/builds/.../gitlab_runner_task/images/kaniko_image: no such file or directory
Previous copy statements (with --from kaniko) work but the last one fails. docker-entrypoint.sh is in the same folder as my Dockerfile.
I found this issue while trying to debug an issue - similarly with building from a GitLab Runner. The error-message was similar to what I see here:
error building image: error building stage: failed to get files used from context: failed to get fileinfo for /kaniko/2/app/public: lstat /kaniko/2/app/public: no such file or directory
The real issue was that /app/public
was empty, so Kaniko didn't save the directory for a later stage, and would therefore error out, where docker build
would have no trouble with copying in an empty directory from a previous stage.
Hope this helps someone.
@anneadb My apologies for the delay; for some reason I never got notified about your message!
I am afraid I don't remember anymore the full context of the issues I encountered or how I ended up solving them, let alone whether I actually saw the bug that the present bug report is about. I have run into so many Gitlab bugs and sometimes also Kaniko bugs in the last months, that it's difficult to recall things sometimes. :sweat_smile:
In any case, what I can tell you is that one should absolutely avoid putting any files in $CI_PROJECT_DIR inside a Docker image, since – when the image is later used in a CI job – Gitlab will mount an outside volume there (the cloned repository) and the files won't be visible, anyway. Unfortunately, if you use a different WORKDIR
for your image (say, /workdir), you might then run into a whole bunch of other Gitlab issues and need to build workarounds for those. I started keeping track of Gitlab bugs in my notes, so here is an excerpt:
- [2024-01] Artifact paths (
artifacts: paths: …
) must be inside and relative to$CI_PROJECT_DIR
both in jobs writing artifacts and in jobs receiving artifacts from earlier jobs, compare- [2024-01] A job's
script
runs in the Docker image's WORKDIR butbefore_script
andafter_script
don't, compare https://gitlab.com/gitlab-org/gitlab-foss/-/issues/32675
Again, I'm not sure what ended up resolving the specific issues I mentioned in my previous message but today we no longer use $CI_PROJECT_DIR in any of our Dockerfiles for the reason I mentioned above, and things generally seem to work fine. (Of course, correlation != causation.) The exception to this is this Kaniko bug, which still hits us occasionally, and also that one.
Sorry I can't be of greater help!
Actual behavior Fails to create image.
Expected behavior Create an image
To Reproduce
Additional Information
empty
is an empty file.touch empty
kaniko
's call:/kaniko/executor --context /docker --no-push --oci-layout-path /container --reproducible
Dockerfile:
Triage Notes for the Maintainers I didn't try with
--cache
--cache
flag