Shell missing in /bin/sh

[luke-plausin-kidsloop]

Hi there, I am using bitbucket pipelines and would like to use Kaniko for a pipeline.
I am following this guide which describes using the Kaniko debug image with Gitlab, specifying the entry point as /busybox/sh:
https://medium.com/01001101/enhance-your-docker-image-build-pipeline-with-kaniko-567afb6cf97c

Sadly there is no option in Bitbucket to set the entrypoint, bitbucket assumes a shell will be present at /bin/sh so I can't execute an official Kaniko image in Bitbucket pipelines. It seems like a lot of tools for Docker and k8s expect a shell to be present at /bin/sh (nerdctl, docker cli and lens all come to mind).

Is there any possibility of putting a shell into the Kaniko debug image at /bin/sh?

[imjasonh]

What version of the image are you using? I believe this was fixed in #1748, with this line:

kaniko/deploy/Dockerfile_debug

Line 79 in 09e70e4

RUN ["/busybox/ln", "-s", "/busybox/sh", "/bin/sh"]

I can also use /bin/sh with the latest commit-tagged image, though that change may not yet be present in :latest

$ docker run -it --entrypoint /bin/sh gcr.io/kaniko-project/executor:09e70e44d9e9a3fecfcf70cb809a654445837631-debug -c 'echo hello'
hello

[simon-liebehenschel]

I do not want to create one more issue, so I found the most (probably) related one.

I use Kaniko at GitLab:

  image:
    name: gcr.io/kaniko-project/executor:v1.9.0-debug

and there is no shell available. E.g. I can not write something like bash my_script.sh in the ".gitlab-ci.yml" file.

Is is an expected behavior?

---

UPDATE

This is not documented, but you must use /busybox/sh. Example for GitLab:

# .gitlab-ci.yml

job_name:

    script:
        - /busybox/sh my_script.sh

[slonopotamus]

There is /bin/sh. And GitLab has docs about Kaniko: https://docs.gitlab.com/ee/ci/docker/using_kaniko.html

[n7k-dobri]

This is a clear regression at some point between Feb 2022 and now. Note the response above:

$ docker run -it --entrypoint /bin/sh gcr.io/kaniko-project/executor:09e70e44d9e9a3fecfcf70cb809a654445837631-debug -c 'echo hello'
hello

That indeed works. It's also an image from Feb 15, 2022

The same command attempted with v1.16.0

$ docker run -it --entrypoint /bin/sh gcr.io/kaniko-project/executor:v1.16.0 -c 'echo hello'
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown.
ERRO[0000] error waiting for container:

Note that /busybox/sh also doesn't work, and neither does sh:

$ docker run -it --entrypoint /busybox/sh gcr.io/kaniko-project/executor:v1.16.0 -c 'echo hello'
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/busybox/sh": stat /busybox/sh: no such file or directory: unknown.
ERRO[0000] error waiting for container:

This is an issue with GitLab kubernetes executor which must use sh to setup scripts. I've burned a day on making this work, and the two solutions that seem most promising right now are:

• Run random image above from Feb 2022
• Make an alpine frankenstein image similar to this other issue

[n7k-dobri]

Correction - this is a difference between the v1.N.0-debug container and v1.N.0/v1.N.0-slim:

$ docker run -it --entrypoint /busybox/sh gcr.io/kaniko-project/executor:v1.16.0-debug -c 'echo hello'
hello

Is this intentional? It seems counter-intuitive that -debug container is the one that works out of the box (with the GitLab kubernetes runners)