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

We've updated the Build UI to be more intuitive with the following improvements:

• The issues tab is called the failures tab, making it easier for you to view failed jobs
• The organization name and avatar are now seen on each Build page, to make it easier view the organization you're editing settings for
• Block steps within groups are now easier to identify in the UI with a thickened purple border
• Pipelines can be bookmarked instead of starred
• Build summary now has a rebuild option, rather than edit steps and new build options
• You can now navigate to all builds by clicking on the builds icon
• Spacing and font fixes

It's also easier to make your pipelines stand out with:

• Pipeline avatars in place of build stats
• Configuration of pipeline color and emoji through pipeline settings

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

The latest agent release includes the job-api experiment, which enables an HTTP API within the agent, allowing jobs to inspect and mutate their environment without using bash. This is a big step towards supporting hooks and plugins in other languages.

Other experimental features include:

• allowing spawning agents with a descending priority, rather than the default ascending priority
• artifacts can now be uploaded to S3 compatible endpoints such as MinIO.

Other updates to this release include:

• the AWS Elastic Stack has been updated with a newer version of buildx
• the managed secrets buckets created by the stack now have public ACLs explicitly blocked

For a full list of additions, changes, fixes, and more details, see the buildkite-agent changelog and the elastic-ci-stack-for-aws changelog on GitHub.

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

See Pipelines glossary to check it out. ✨

The 3.44.0 version of the buildkite-agent and the 5.17.0 version of the AWS elastic stack are now available.

Major updates to the agent include:

• New experiment for running jobs under Kubernetes
• Docker images based on Ubuntu 22.04
• The ability to add claims to OIDC token requests

This agent release has been added to the 5.17.0 release of the elastic stack, as well as support for c7gn, m7g, and r7g instance type classes, and updates to Docker, Docker Compose, buildx, git, and the Linux kernel.

For a full list of additions, changes, and fixes, see the buildkite-agent changelog and the elastic-ci-stack-for-aws changelog on GitHub.

Update: This change has now been completed.

Over the past two years, GitHub, GitLab, and other Git services have updated their default branch names from "master" to "main" – you can read more about the motivation for the change in this statement from the Software Freedom Conservancy.

In line with this change, we will be updating the default branch for newly created pipelines from "master" to "main" from April 1st, 2023. This will not impact existing pipelines.

You can configure a given pipeline's default branch through the user interface, as well as the REST API and GraphQL.

If you would like to retain "master" as the default branch of new pipelines, you may set an organization-level default branch in Pipeline Settings, which will then be used for new pipelines:

If you've ever thought "I need more purple in my life" then we've got some exciting news for you... 💜

We've made some changes to make navigation as simple and obvious as possible across all parts of the product. We've introduced a more familiar navigation pattern to Test Analytics, updated the global nav to clearly identify where you are in the app, and introduced a new visual style to the sidebar. It's a coat of paint, but also a foundation for the features and improvements you can expect in the coming months.

We're focused on the next-generation of Buildkite—from small improvements to whole new products and experience–so you can consider this just a taste of what's to come.

Read the full post

We've updated the navigation in the documentation to help you find the content you need quickly. 🎉

These changes include:

• Having the on-page navigation highlight which section you're reading.
• Revamping the style of the global navigation bar to a single row.
• Focusing on up-to-date and high-value pages like security while deemphasizing deprecated content.
• Highlighting the Overview page and Getting started guide for Pipelines.
• Updating the typography to improve readability.

Try out the new navigation

Pipelines now considers your current branch when surfacing options for a new build. This removes the friction of a new build defaulting to main.

This has been a highly-requested feature from our customers, and we’re so excited to share that the change is now live.

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. 📚

The v3.43.1 version of the buildkite-agent and the v5.16.1 version of the AWS elastic stack are now available.

Agent v3.43.1 fixes a bug introduced in v3.43.0 where jobs running on agents in --acquire-job mode will fail after about ~4.5 minutes. Agents running in non-acquire mode are not affected, and most of our customers don't use --acquire-job mode.

AWS Elastic Stack v5.16.1 upgrades the agent to this new version. Most elastic stack installations will not be affected by the above agent bug, but we still recommend upgrading to the latest version.

For a full list of additions, changes, and fixes, see the buildkite-agent changelog and the elastic-ci-stack-for-aws changelog on GitHub.

The 3.43.0 version of the buildkite-agent and the 5.16.0 version of the AWS elastic stack are now available.

This agent release fixes a panic that was accidentally added in v3.42.0, adds a flag to allow empty results with doing an artifact search, and Docker images for linux/arm64. Also, start --acquire-job now retries while the job is locked.

This agent release has been added to the 5.16.0 release of the elastic stack, which also includes Git v2.39.1 to address recent security vulnerabilities in Git, and now pushes access logs to Cloudwatch for Linux instances.

Two weeks ago we released the 3.42.0 version of the agent and the 5.15.0 version of the AWS elastic stack. This agent has added an experimental inbuilt status page, and a new agent-startup hook. The 5.15.0 release of the elastic stack added a parameter to enable server side encryption on s3 buckets created in the stack.

For a full list of additions, changes, and fixes, see the buildkite-agent changelog and the elastic-ci-stack-for-aws changelog on GitHub.

Customers using SSO authentication can now easily configure the SSO session duration via the settings UI–enabling greater control over your security posture.

Once the specified duration elapses, the user session will expire requiring re-authentication to access Buildkite.

Learn more about how to set up your SSO session duration