Closed orien closed 2 years ago
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.
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"]
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.
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).