The kubernetes plugin uses the Kubernetes definition of podSpec. Kubernetes defines the command and args of a container to mean a single command entrypoint for the container (command is called entrypoint in some other container runtimes). To be as compatible as possible with Kubernetes and existing users, the default interpretation of command and args should remain consistent whether or not it is being passed through BUILDKITE_COMMAND.
results in $BUILDKITE_COMMAND equal to my_command subcommand hello 123 foo.
Some people would like command to be interpreted as it would for a (non-Kubernetes) command step: it can be one or more commands (as a list). These are joined with \n before being passed through BUILDKITE_COMMAND.
If you have only one container in the podSpec, or multiple containers that run the same command, then there's no need for this new option: just use the command at the step level. It will be interpreted in the Buildkite way (multiple commands).
However, if podSpec defines multiple containers, and they need to run different commands, and a single command entrypoint is undesirable, and they don't want to explicitly call a shell to process multiple commands...
...then this new multi_command option can be used to interpret the command list as multiple commands.
For example:
plugins:
- kubernetes:
multi_command: true
podSpec:
containers:
- name: echo
command: ["my first command", "my other command"]
args: ["hello", "123", "foo"]
The
kubernetes
plugin uses the Kubernetes definition ofpodSpec
. Kubernetes defines thecommand
andargs
of acontainer
to mean a single command entrypoint for the container (command
is calledentrypoint
in some other container runtimes). To be as compatible as possible with Kubernetes and existing users, the default interpretation ofcommand
andargs
should remain consistent whether or not it is being passed throughBUILDKITE_COMMAND
.For example:
results in
$BUILDKITE_COMMAND
equal tomy_command subcommand hello 123 foo
.Some people would like
command
to be interpreted as it would for a (non-Kubernetes) command step: it can be one or more commands (as a list). These are joined with\n
before being passed throughBUILDKITE_COMMAND
.If you have only one container in the
podSpec
, or multiple containers that run the same command, then there's no need for this new option: just use thecommand
at thestep
level. It will be interpreted in the Buildkite way (multiple commands).However, if
podSpec
defines multiple containers, and they need to run different commands, and a single command entrypoint is undesirable, and they don't want to explicitly call a shell to process multiple commands......then this new
multi_command
option can be used to interpret thecommand
list as multiple commands.For example:
results in
$BUILDKITE_COMMAND
equal to