Clusters allow you to organize agents into groups. These groups, or clusters, will enable the management of pipelines and queues within that cluster.

Clusters can be turned on by an admin by accessing pipeline settings in the organization settings tab. Note that once clusters is enabled, you will be unable to disable it.

Learn more about clusters

You can now request an OpenID Connect (OIDC) token from the Buildkite Agent 🔑

OIDC tokens are JWTs signed by Buildkite and decode into JSON which includes many attributes like the pipeline slug and the build branch. buildkite-agent oidc request-token will return a token representing the current job that can be exchanged with federated systems to authorize actions like deployments or allow access to context-sensitive information like secrets based on these attributes.

Learn more about OpenID Connect support from the Buildkite Agent

Explore organization change events in your existing AWS monitoring suite.

Enterprise customers can now route Buildkite Audit Log events via the AWS Event Bridge event bus.

Learn more about configuring Buildkite with AWS EventBridge

Restrict API access to IP addresses and CIDR block ranges you trust.

You can now easily create and manage a list of IP addresses and CIDR blocks that are authorized to access your organization via the Buildkite API, improving security and reducing the risk of unauthorized access.

Learn more about configuring IP/CIDR allowlist via the UI, API, or Terraform

Jobs that belong to group steps will now have access to information about their group with three new environment variables:

• BUILDKITE_GROUP_ID
• BUILDKITE_GROUP_KEY
• BUILDKITE_GROUP_LABEL

You could use these variables to upload steps to the same group, or alter the behaviour of jobs based on their group. These environment variables will be absent for jobs that do not belong to group steps.

Learn more about environment variables

Jobs can now be automatically retried based on the signal received by the command process that caused it to exit, in addition to the job's exit code.

This is particularly useful in catching terminated agent hosts, such as you'd see when using EC2 Spot Instances:

1
2
3
4
5
6
7
8
9
10
11
  - label: "Tests"
    command: "tests.sh"
    retry:
      automatic:
        # Catch cleanly-terminated instances
        - limit: 2
          signal_reason: "agent_stop"
        # Catch timed-out agents
        - limit: 2
          exit_status: -1
          signal_reason: none

Learn more about the new attributes

Build Matrix has been extended to support matrix variable interpolation inside the plugins and agents attributes of command steps.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
steps:
- label: "💥 Matrix Build"
  command: "echo {{matrix.os}} {{matrix.arch}}"
  agents:
    queue: "builder-{{matrix.arch}}"
  matrix:
    setup:
      arch:
        - "amd64"
        - "arm64"
      os:
        - "windows"
        - "linux"
  plugins:
    - artifacts#v1.9.0:
        upload: "out/{{matrix.arch}}.gz"

Learn more about increased Build Matrix support

The waterfall view visualizes the timeline of each step in a build. You can see this summary in your Builds page a toggle–enabling to switch between list and waterfall views.

Quickly view insights about failed tests by going directly from a job to its related information in Test Analytics – providing a faster path from fail to fix.

Flaky tests are automated tests that produce inconsistent or unreliable results, despite being run on the same code and environment. They cause frustration, decrease confidence in testing, and waste time while you investigate whether the failure is due to a genuine bug.

Test Analytics finds your flakes by surfacing when the same test is run multiple times on the same commit SHA with different results. The tests might run multiple times within a single build or across different builds. Either way, they are detected as flaky if they report both passed and failed results.

Results are available in the Test Analytics UI and via a new REST API endpoint.

Learn more about flaky test tracker and its API

Pipeline tags make it easier to sort through and filter multiple pipelines. Tag names support both text and emojis. You can now tag your pipelines and use the search bar to find tags.

Tags are unique per pipeline, don't contain line breaks and are capped at 64 characters. You can have 5 tags per pipeline.

Tags can also be set through REST and GraphQL APIs.

To set the tags, go to Pipeline Settings > General > Tags

Analyze your usage by pipeline or test suite, with the option to view monthly or daily breakdowns. Delve into previous billing periods, and conveniently export your data for offline analysis.

Learn more about usage breakdown

We've added a glossary to highlight and explain the core concepts of pipelines.

See Pipelines glossary to check it out. ✨

We’ve added a guide to help you set up merge queues in your pipelines. Merge queues are a feature of GitHub to improve development velocity on busy branches. ✨

See Using GitHub merge queues to learn more. 📚

Job logs now have the addition of light theme on build summaries – ensuring those that find lower contrast easy-to-read have an alternative option.

Unblocking engineers - and your work – is the core theme of how we think of everything here at Buildkite, including usability. The new light theme was inspired by Ethan Schoonover's Solarized theme. Now, when you open a job log, you’ll see a new “Theme” control – enabling you to switch between our current dark mode theme and the new light theme. Your preference will be saved for future views, with the option for you to switch views.

As always, we'd love your feedback. Drop into our Slack community, or send us an email: hello@buildkite.com 👋

Today we’re introducing the ability to configure multiple GitHub Enterprise Servers.

Some of our bigger teams with different requirements for source control have multiple GitHub Enterprise Server installations. We’ve only supported one per Buildkite organization — until now. If you’re on a compatible plan, you can now add as many different servers as you like from the repository providers page in your organization settings.

We love feedback! If you use this feature and love it, or it doesn’t quite do what you need, drop into our Slack community, or send us an email: hello@buildkite.com 👋

Failed builds now jump straight to a new Issues tab on the build page 🗂

Builds with hundreds of jobs can hide what really matters. Instead of scrolling through the noise, Issues shows you only the failed annotations and jobs in a build. This helps you get your code shipping faster. And the rest of your jobs are only a tab click away.

Check out the blog post to learn more about this change.

As always, we'd love your feedback. Drop into our Slack community, or say hi: hello@buildkite.com 👋

Update, Sep 2023: We are no longer offering per pipeline build retention. For more information on retention per plan, see check out the docs.

Today, we're introducing build retention controls for pipelines so you can automatically remove old builds ⏰🧨

You can now configure pipelines to keep builds for a certain period of time. There's also an option to always keep a minimum number of the latest builds, so you don't lose context on pipelines that don't move quite so fast. These are available today — find any pipeline, then go to Settings, Builds, and look for the Build Retention section.

This change is currently optional, but we'll be announcing a broader rollout for build retention soon.

We'd love to hear from you if you find these controls useful, or if they don't quite fit your needs first. Drop into our Slack community, or send us an email: hello@buildkite.com 👋

We've released a new schema browser for our GraphQL API 🎉

You can now easily browse the entire structure of the API right there in the docs, without needing to log in first

You can now specify default timeouts for command steps ⏰💥

Timeouts can be specified on command steps already, but it's a pain to have to do it every time, and easy to forget. Setting default timeouts means you won't have command steps slip through the cracks and accidentally run forever, or consume too many job minutes.

Default and maximum timeouts can be specified at an organization and pipeline level. Defaults apply in order of specificity — the step's timeout will be used if supplied, otherwise it defaults to the pipeline's default if supplied, or finally to the organization. Maximums are always enforced, when supplied — the smallest value will be used.

These timeouts can be configured from your organization's Pipeline Settings page, or on a pipeline's Builds settings page.

We'd love to hear from you if you find these timeouts useful, or if they don't quite fit your needs first. Drop into our Slack community, or send us an email: hello@buildkite.com 👋