You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we're having the checkout container copy the ~/.ssh directory and set permissions on it, taking advantage of the fact that it previously didn't have a command phase.
The problem is that a common pattern for when we're using Alpine Linux containers is to setBUILDKITE_SHELL to /bin/sh, because Alpine doesn't come out of the box with bash. With the way that the environment gets set in each of these containers, this means that BUILDKITE_SHELL then gets set to that on the checkout container, resulting in this weird error of
/bin/sh: can't open 'trap 'kill -- $' INT TERM QUIT; cp -r ~/.ssh /workspace/.ssh && chmod -R 777 /workspace': No such file or directory
One way of solving this would be to just not set BUILDKITE_SHELL on the checkout container, we already do some kind of deny-listing like this with other parts of the environment.
Another way would be to find the minimum subset of variables that the system containers need (agent, checkout, artifact upload), and only give the entire environment to the command/sidecar containers.
A third way we could solve this would be to move this logic into the agent itself, rather than using the command step like this.
A way that users can work around this is to set the env only on the specific Alpine container, but I'm thinking that the current default when you set env at the step level might be surprising behavior for some.
The text was updated successfully, but these errors were encountered:
Right now we're having the
checkout
container copy the~/.ssh
directory and set permissions on it, taking advantage of the fact that it previously didn't have acommand
phase.The problem is that a common pattern for when we're using Alpine Linux containers is to set
BUILDKITE_SHELL
to/bin/sh
, because Alpine doesn't come out of the box with bash. With the way that the environment gets set in each of these containers, this means thatBUILDKITE_SHELL
then gets set to that on the checkout container, resulting in this weird error ofOne way of solving this would be to just not set
BUILDKITE_SHELL
on the checkout container, we already do some kind of deny-listing like this with other parts of the environment.Another way would be to find the minimum subset of variables that the system containers need (agent, checkout, artifact upload), and only give the entire environment to the command/sidecar containers.
A third way we could solve this would be to move this logic into the agent itself, rather than using the command step like this.
A way that users can work around this is to set the env only on the specific Alpine container, but I'm thinking that the current default when you set
env
at the step level might be surprising behavior for some.The text was updated successfully, but these errors were encountered: