v0.10.0 (2024-06-25)

Full Changelog

⚠️ This release has some breaking changes to the signature subpackage.

All the following functions now take as their first param a context.Context, as well as the following changes.

The signature of signature.Sign function has changed to no longer take env map[string]string but instead use signature.WithEnv(env) as an option.

-func Sign(key jwk.Key, env map[string]string, sf SignedFielder) (*pipeline.Signature, error)
+func Sign(_ context.Context, key jwk.Key, sf SignedFielder, opts ...Option) (*pipeline.Signature, error)

The signature of signature.Verify function has also changed to take signature.WithEnv(env) as an option instead of env map[string]string.

-func Verify(s *pipeline.Signature, keySet jwk.Set, env map[string]string, sf SignedFielder)
+func Verify(ctx context.Context, s *pipeline.Signature, keySet jwk.Set, sf SignedFielder, opts ...Option) error

The signature of signature.SignSteps function has also changed to take signature.WithEnv(env) as an option instead of env map[string]string.

-func SignSteps(s pipeline.Steps, key jwk.Key, env map[string]string, repoURL string)
+func SignSteps(ctx context.Context, s pipeline.Steps, key jwk.Key, repoURL string, opts ...Option) error

Added

The following were added to the signature subpackage.

func WithEnv(env map[string]string) Option
func WithLogger(logger Logger) Option
func WithDebugSigning(debugSigning bool) Option

• WithLogger enables logging public key thumbprints when signing and verifying steps
• WithDebugSigning will enable debugging for signing steps. When this is enabled, along with WithLogger, will log step payloads before they are signed to assist in debugging verification failures
  • This is intended for development purposes
  • During step upload using signing this will log step payloads to the jobs log which could leak secrets to those with access to your Buildkite build page ⚠️
  • During step verification at the start of all signed jobs this will log the step payloads to the agent log

Removed

-func SignPipeline(p *pipeline.Pipeline, key jwk.Key, repo string) error

Call SignSteps instead.

Changed

• (Described above) Log public key fingerprint in debug, log step payload in signing-debug #39 (@patrobinson)
• Bump github.com/lestrrat-go/jwx/v2 from 2.0.21 to 2.1.0 #40 (@dependabot[bot])
• Bump github.com/buildkite/interpolate from 0.0.0-20200526001904-07f35b4ae251 to 0.1.2 #38 (@dependabot[bot])

v0.9.0 (2024-04-26)

Full Changelog

⚠️ This release has some breaking changes.

the signature of the pipeline.(*Pipeline).Interpolate method has changed to require an extra argument:

func (p *Pipeline) Interpolate(interpolationEnv InterpolationEnv, preferRuntimeEnv bool) error

This allows us to re-introduce the behaviour of the runtime environment taking precedence if this flag is set to true.

Added

• Add back preferred runtime env with option by @patrobinson in #36

What's Changed

• Revert breaking change to precedence of variables by @patrobinson in #35

New Contributors

• @patrobinson made their first contribution in #35

Full Changelog: v0.7.0...v0.8.0

What's Changed

• Add support for name and size to Cache by @jordandcarter in #34
• Add support for cache: false on a CommandStep by @jordandcarter in #34

New Contributors

• @jordandcarter made their first contribution in #34

Full Changelog: v0.6.0...v0.7.0

What's Changed

• Update Go to 1.22 by @moskyb in #32
• Add cache settings block to pipeline.CommandStep by @moskyb in #33

Full Changelog: v0.5.1...v0.6.0

What's Changed

• Warnings fix and improvements by @DrJosh9000 in #31

Full Changelog: v0.5.0...v0.5.1

🗒️ Some input pipelines will now parse with a non-nil error, that didn't before. Code that calls Parse should check for the new error type provided by the warning package before aborting, since the parsed pipeline could still be accepted by Buildkite.

What's Changed

• Remove newlines from ordered.Map JSON by @DrJosh9000 in #25
• System for reporting warnings (soft errors) by @DrJosh9000 in #27
• Bump github.com/lestrrat-go/jwx/v2 from 2.0.19 to 2.0.20 by @dependabot in #28
• fix: Env test flakes on Windows by @DrJosh9000 in #29
• Bump github.com/lestrrat-go/jwx/v2 from 2.0.20 to 2.0.21 by @dependabot in #30

Full Changelog: v0.4.1...v0.5.0

What's Changed

• Cleanup docs and tests after v0.4.0 by @triarius in #21
• fix: YAML marshaling of wait, block, and input by @DrJosh9000 in #22
• chore: reduce repetition in wait/input step marshaling by @DrJosh9000 in #23
• chore: lots more YAML marshaling in tests by @DrJosh9000 in #24

Full Changelog: v0.4.0...v0.4.1

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

v0.3.2 (2023-12-14)

Full Changelog

Fixed

• Fix maps with aliases as keys #18 (@DrJosh9000)