The Buildkite Agent is an open-source toolkit written in Go for securely running build jobs on any device or network
--spawn-per-cpu The number of agents to spawn per cpu in parallel (mutually exclusive with --spawn) #2711 (@mmlb)name and size command step settings, support cache: false) #2731 (@jordandcarter)tool sign usage description to match actual command #2677 (@CheeseStick)avoid-recursive-trap experiment #2669 (@triarius)wait, block, and input scalar steps (when using tool sign or pipeline upload --format=yaml) #2640 (@DrJosh9000)[!WARNING] This release has two potentially breaking changes in the way environment variables are interpolated.
Interpolation on Windows should be done in a case-insensitive manner to be compatible with Batch scripts and Powershell. This was working correctly up until some refactoring in v3.59.0.
For example, this pipeline:
env:
FOO: bar
steps:
- command: echo $Foo $FOO
should now be correctly interpolated on Windows as:
env:
FOO: bar
steps:
- command: echo bar bar
Interpolation on other platforms is unchanged.
Our documented interpolation rules implies that variables from the agent environment have higher precedence than variables defined by the job environment ("we merge in some of the variables from the agent environment").
Suppose the agent environment contains FOO=runtime_foo. The pipeline
env:
BAR: $FOO
FOO: pipeline_foo
steps:
- command: echo hello world
would in previous releases be interpolated as:
env:
BAR: runtime_foo
FOO: pipeline_foo
steps:
- command: echo hello world
On the other hand, the pipeline
env:
FOO: pipeline_foo
BAR: $FOO
steps:
- command: echo hello world
would be interpolated to become
env:
FOO: pipeline_foo
BAR: pipeline_foo
steps:
- command: echo hello world
We think this is inconsistent with the agent environment taking precedence,
and if users would like to interpolate $FOO as the value of the pipeline
level definition of FOO, they should ensure the agent environment does not
contain FOO.