-
Notifications
You must be signed in to change notification settings - Fork 107
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
entrypoint: false doesn't disable default image entrypoint #138
Comments
Sorry you've hit this bug. I believe this is being addressed in #132, though it hasn't been updated in while. |
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.
|
Sorry for resurrecting this issue, but is there any update on fixing this? I've just tested using the steps:
- label: ":shipit: Deploy"
command:
- echo "Hi"
plugins:
- docker#v3.8.0:
image: amazon/aws-cli:2.2.27
entrypoint: false # Disable default entrypoint. |
Until buildkite-plugins#138 is resolved (possibly by buildkite-plugins#132), this documentation update should save users some pain when trying to override or disable the default entrypoint for a container.
Until buildkite-plugins#138 is resolved (possibly by buildkite-plugins#132), this documentation update should save users some pain when trying to override or disable the default entrypoint for a container.
Until buildkite-plugins#138 is resolved (possibly by buildkite-plugins#132), this documentation update should save users some pain when trying to override or disable the default entrypoint for a container.
This was fixed on PR #208 🙌🏻 |
In v3.3.0, the
entrypoint
documentation specifies:However, doing so doesn't disable the entrypoint and I see no
--entrypoint
flag in the loggeddocker run
command.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 forterraform
.Work-around
Setting this attribute to an empty string seems to produce the desired behaviour.
Suggestion
I think we should update the plugin behaviour to match the documentation (alternatively, update the documentation to match the plugin behaviour).
The text was updated successfully, but these errors were encountered: