Unable to use buildpacksio/pack:latest image in GitLab

[anoopvlcy]

Summary

When we use _buildpacksio/pack:latest as Gitlab CI image, the build is failing with below error.

ERROR: Job failed (system failure): Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "sh": executable file not found in $PATH: unknown (exec.go:73:0s)

Reproduction

Create Gitlab CI template and run pipeline

however when we use older version of "buildpacksio/pack" image (say 0.12.0) its working as expected

Steps

1. Create ci template job with following image
   .test-base:
   image:
   name: "buildpacksio/pack:latest"
   entrypoint: [""]
2. Run pipeline
   Return above mentioned error.

Current behavior

Returns error
ERROR: Job failed (system failure): Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "sh": executable file not found in $PATH: unknown (exec.go:73:0s)

Expected behavior

Should not return error and should be able to run shell scripts

Environment

[natalieparellano]

@dfreilich do you have any insights here?

[dfreilich]

That makes sense, to some degree, based on how GitlabCI images work. They inject the entrypoint given by referring to a shell, and since we build the image with the tiny stack, there is no shell on the image. You should be able to avoid that by providing a script. I can try testing it out tomorrow and verify that.

What configuration are you trying to give in the job?

[anoopvlcy]

hi @dfreilich,

I was trying below job in Gitlab:

default:
tags:
- "privileged"

variables:
CI_REGISTRY_IMAGE: "$CI_REGISTRY/test/$CI_PROJECT_NAME"

cnb-build-image:
stage: build
image:
name: "buildpacksio/pack:latest"
entrypoint: [""]
script:

• pack build "$CI_REGISTRY_IMAGE" --builder "paketobuildpacks/builder:latest" --volume "$(pwd)/binding:/platform/bindings/new-relic" -b paketo-buildpacks/java -b paketo-buildpacks/new-relic --env BP_JVM_VERSION=17

stages:

• build
• test
• package-build
• package-test
• infra
• deploy
• acceptance
• publish
• infra-prod
• production

---

I also tried entrypoint: ["/bin/sh", "-c"] as mentioned in gitlab, but it didn't worked as well. obviously not shell would have caused this

As per Gitlab documentation:

The image you choose to run your build in via image directive must have a working shell in its operating system PATH. Supported shells are sh, bash, and pwsh (since 13.9) for Linux, and PowerShell for Windows. GitLab Runner cannot execute a command using the underlying OS system calls (such as exec).

Please let me know your test outcome.

[natalieparellano]

@anoopvlcy I think the problem you are encountering is due to the pack image not having a shell. Can you try providing pack as the entrypoint and the rest of your command as the args?

[natalieparellano]

As an alternative, you may get this to work by enabling Auto DevOps; the guide can be found here: https://buildpacks.io/docs/tools/gitlab/ and here: https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-build-using-cloud-native-buildpacks

[anoopvlcy]

@anoopvlcy I think the problem you are encountering is due to the pack image not having a shell. Can you try providing pack as the entrypoint and the rest of your command as the args?

I tried this already. Gitlab requires a shell to execute

[anoopvlcy]

As an alternative, you may get this to work by enabling Auto DevOps; the guide can be found here: https://buildpacks.io/docs/tools/gitlab/ and here: https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-build-using-cloud-native-buildpacks

I have seen auto devops before... We are not planning to use Auto DevOps for our use case.
The Gitlab AutoDev ops uses a Custom image with Pack CLI in it. Probably they have gone this path due to lack of shell in Pack image. Maintaining our own custom image is having maintenance overhead.

[dfreilich]

Makes sense. I think it could make sense for us to release a pack image with a shell (built with the :base builder instead of the :tiny builder), which should solve your problem.

[sidmohanty11]

@dfreilich In paketobuildpacks/builder:base we are using ubuntu:bionic which comes with sh built in. How should we approach this?

[joe-kimmel-vmw]

@dfreilich - I see a couple of paths here and wonder which you prefer or what i'm missing:

• a one-liner edit that changes tiny to base ( https://github.com/buildpacks/pack/blob/main/.github/workflows/delivery-docker.yml#L19 ) though maybe that would come with downsides for all other users?
• a copy of the delivery-docker.yml file with the same change as above, so that there's a separate build artifact that consumers could select as needed.
• or is it more complicated?

[natalieparellano]

If we are making changes to the pack image, this issue is possibly related: #1579

[exitflynn]

hi there, I'd like to work on solving this!

[StanislawFlexpedia]

Hi, is there any update for this issue? I'm having the same problem - buildpacks can't be used in gitlab ci.

[natalieparellano]

@buildpacks/platform-maintainers any thoughts on this one?

[dfreilich]

Thanks for the pings 😄 . Let's rework the delivery-docker.yml workflow, once #1745 is merged in, to publish two images using a matrix, one based on the paketobuildpacks/builder-jammy-tiny builder and one based on paketobuildpacks/builder-jammy-base, which should take care of this

[natalieparellano]

Sounds good - I'd also suggest using the tags buildpacksio/pack:tiny (this image should continue to claim buildpacksio/pack:latest) and buildpacksio/pack:base.

[icruces]

Any update on this? I am just facing the same problem.

[natalieparellano]

@icruces thanks for the ping - I've pulled this issue into the next milestone. Hopefully it could get the attention it deserves as more cycles are freed up (once we ship pack 0.30.0). If anyone is interested in contributing this as suggested in #1554 (comment) that could help it move faster.