Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use buildpacksio/pack:latest image in GitLab #1554

Closed
anoopvlcy opened this issue Nov 18, 2022 · 18 comments · Fixed by #1951
Closed

Unable to use buildpacksio/pack:latest image in GitLab #1554

anoopvlcy opened this issue Nov 18, 2022 · 18 comments · Fixed by #1951
Assignees
Labels
good first issue A good first issue to get started with. help wanted Need some extra hands to get this done. size/sm Small level of effort type/enhancement Issue that requests a new feature or improvement.
Milestone

Comments

@anoopvlcy
Copy link

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

@anoopvlcy anoopvlcy added status/triage Issue or PR that requires contributor attention. type/bug Issue that reports an unexpected behaviour. labels Nov 18, 2022
@natalieparellano
Copy link
Member

@dfreilich do you have any insights here?

@dfreilich
Copy link
Member

dfreilich commented Nov 20, 2022

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
Copy link
Author

anoopvlcy commented Nov 21, 2022

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
Copy link
Member

@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
Copy link
Member

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
Copy link
Author

@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
Copy link
Author

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
Copy link
Member

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.

@dfreilich dfreilich added type/enhancement Issue that requests a new feature or improvement. help wanted Need some extra hands to get this done. size/sm Small level of effort good first issue A good first issue to get started with. and removed type/bug Issue that reports an unexpected behaviour. status/triage Issue or PR that requires contributor attention. labels Nov 23, 2022
@sidmohanty11
Copy link

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

@joe-kimmel-vmw
Copy link
Contributor

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

@natalieparellano
Copy link
Member

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

@exitflynn
Copy link

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

@StanislawFlexpedia
Copy link

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

@natalieparellano
Copy link
Member

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

@dfreilich
Copy link
Member

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
Copy link
Member

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
Copy link

icruces commented Aug 3, 2023

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

@natalieparellano natalieparellano added this to the 0.31.0 milestone Aug 3, 2023
@natalieparellano
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue A good first issue to get started with. help wanted Need some extra hands to get this done. size/sm Small level of effort type/enhancement Issue that requests a new feature or improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants