buildkite-plugins / docker-buildkite-plugin

🐳📦 Run any build step in a Docker container
MIT License
113 stars 106 forks source link

entrypoint: false doesn't disable default image entrypoint #138

Closed orien closed 2 years ago

orien commented 5 years ago

In v3.3.0, the entrypoint documentation specifies:

Set it to false to disable the default entrypoint for the image.

However, doing so doesn't disable the entrypoint and I see no --entrypoint flag in the logged docker run command.

steps:
  - command: ls
    plugins:
      - docker#v3.3.0:
          image: hashicorp/terraform:light
          entrypoint: false
docker run -it --rm --init --volume /var/lib/buildkite-agent/builds/xxxx:/workdir --workdir /workdir --env BUILDKITE_JOB_ID --env BUILDKITE_BUILD_ID --env BUILDKITE_AGENT_ACCESS_TOKEN --volume /usr/bin/buildkite-agent:/usr/bin/buildkite-agent --label com.buildkite.job-id=6b701e83-acb8-4834-a129-ccb3266577a7 hashicorp/terraform:light /bin/sh -e -c ls

Here the default entrypoint is being used and for this image ends up running terraform /bin/sh -e -c ls. This fails because /bin/sh is an invalid subcommand for terraform.

Work-around

Setting this attribute to an empty string seems to produce the desired behaviour.

entrypoint: ""
docker run -it --rm --init --volume /var/lib/buildkite-agent/builds/xxxx:/workdir --workdir /workdir --env BUILDKITE_JOB_ID --env BUILDKITE_BUILD_ID --env BUILDKITE_AGENT_ACCESS_TOKEN --volume /usr/bin/buildkite-agent:/usr/bin/buildkite-agent --entrypoint '' --label com.buildkite.job-id=107582c8-92e5-4a95-8e34-93523f5c6a82 hashicorp/terraform:light ls

Suggestion

I think we should update the plugin behaviour to match the documentation (alternatively, update the documentation to match the plugin behaviour).

toolmantim commented 5 years ago

Sorry you've hit this bug. I believe this is being addressed in #132, though it hasn't been updated in while.

kylecordes commented 5 years ago

Ouch, this one was tricky. After some failed experimentation this bug report was vital reading. I suggest a quick fix to the docs until there is time to fix the problem.

On a more specific note, for the next person to come along trying to get a container image to work, the following works on Google's Bazel container.

steps:
  - commands:
      - cd somewhere
      - bazel build ...
      - bazel test ...
      - bazel run :something
    label: "Build, test, and run some things."
    plugins:
      - docker#v3.2.0:
          image: "l.gcr.io/google/bazel:latest"
          entrypoint: ""
          shell: ["/bin/bash", "-c"]
software-opal commented 3 years ago

Sorry for resurrecting this issue, but is there any update on fixing this? I've just tested using the v3.8.0 plugin and still have this issue but I could be doing something wrong:

steps:
  - label: ":shipit: Deploy"
    command:
    - echo "Hi"
    plugins:
      - docker#v3.8.0:
          image: amazon/aws-cli:2.2.27
          entrypoint: false  # Disable default entrypoint.
pzeballos commented 2 years ago

This was fixed on PR #208 🙌🏻