v0.4.0

v0.4.0 (2024-02-09)

Full Changelog

⚠️ This release has some breaking changes.

Firstly, the type that is required to be passed into pipeline.(*Pipeline).Interpolate has changed from a map[string]string to an interface, pipeline.InterpolationEnv.

type InterpolationEnv interface {
	Get(string) (string, bool)
	Set(string, string)
}

This allows some equivalence between environment variable names to be established by the user, for example, on Windows, the environment variable names may be case-insensitive. If the implementation supports this, the pipeline interpolation will also support this. For example, this pipeline:

steps:
- command: echo $Foo $FOO

with an InterpolationEnv that whose Get method returns "bar" for "foo" regardless of the case, will be interpolated to

steps:
- command: echo bar bar

Previously, it was not possible to do this without adding the case-variants to the map[string]string.

Another breaking change is that previously, when interpolating the pipeline level environment block, a pipeline level environment variable could take precedence over environment variables in the argument to pipeline.(*Pipeline).Interpolate (aka the runtime env in the context of a job running on an agent) depending on the ordering. This may have contravened Buildkite's documentation that suggests the Job runtime environment takes precedence over that defined by combining environment variables defined in a pipeline. This led to results like this:

Suppose the runtime env consisted of FOO=runtime_foo. The following pipeline

env:
  BAR: $FOO
  FOO: pipeline_foo
steps:
- command: echo hello world

would be interpolated to become:

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 runtime env taking precedence, and if users would like to interpolate $FOO as the value of the pipeline level definition of FOO, they should ensure the runtime env does not contain FOO=runtime_foo.

Fixed

• Environment variable interpolation was not capable of being case-insensitive on Windows #20 (@triarius)
• Precedence of Runtime Variables over Pipeline and Step Environment variables, even after they collide after interpolation #20 (@triarius)

Dependencies

• Bump github.com/lestrrat-go/jwx/v2 from 2.0.18 to 2.0.19 #19 (@dependabot[bot])