buildkite / agent-stack-k8s

Spin up an autoscaling stack of Buildkite Agents on Kubernetes
MIT License
77 stars 27 forks source link

[WIP] Add multi_command option #309

Open DrJosh9000 opened 3 months ago

DrJosh9000 commented 3 months ago

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.

For example:

plugins:
- kubernetes:
    podSpec:
      containers:
        - name: echo
          command: ["my_command", "subcommand"]
          args: ["hello", "123", "foo"]

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"]

results in $BUILDKITE_COMMAND equal to

my first command
my other command hello 123 foo