Group steps on the build canvas are now collapsed by default, making complex dependency graphs much easier to follow at a glance.

• Collapsed by default: Group steps are now collapsed when you open a build, reducing visual noise and improving page performance on large pipelines.
• Expand and collapse all: A new button on the canvas lets you expand or collapse all group steps at once. You can also press G to toggle.

• Auto-expand on failure or input: Groups containing failed steps or steps waiting for user input are automatically expanded, so you never miss something that needs your attention.

You can still expand or collapse individual group steps by clicking on them.

The Buildkite Remote MCP server now rate limits on a per-user basis, so one person can't chew through your organization's entire API quota.

If you've been hesitant to roll out the remote MCP server broadly, this should help. Each user gets their own limit of 50 requests per minute, so you can invite your whole team to connect their AI coding assistants to Buildkite without worrying about one heavy user blocking everyone else.

There's nothing to configure, per-user limits apply automatically. If someone hits their limit, only their requests are throttled. Everyone else carries on as normal.

For more on API rate limits across Buildkite, see the Remote MCP server limits documentation.

We've been busy making changes to the way the Buildkite CLI can authenticate against organizations. We've implemented some features, as well as improvements to security so folks can feel safer in giving the CLI assess to their Buildkite organization.

OAuth availability

The CLI can now be authenticated via OAuth, with permissions scoped within the user's own accepted access. The permissions can also be customized to meet your needs for CLI use.

A single auth family

We've introduced an auth command, with various subcommands, to ensure all things authentication can be found in a logical spot. whoami and use can still be used, for now, performing the same actions as their new subcommands, bk auth status and bk auth switch, respectively.

We've also implemented bk auth login, replacing configure add, and bk auth logout, a new command which will clear keychain credentials for the current authenticated organization, or all keychain configurations with the --all flag.

No more text-based tokens

The CLI, until now, has been writing API tokens to a config file, typically at ~/.config/bk.yaml, which is convenient but a pattern we've wanted to move away from. As of v3.32.0, we'll no longer write to this file, only read from it. API tokens will be encrypted and stored in the OS keychain exclusively.

The CLI will fall back to reading bk.yaml files, so if those are in use, or you wish to continue using them, you can, you'll just see a warning in the terminal when you do. If you do wish to store API tokens in your bk.yaml file, you can manually adjust the file;

organizations:
  my-cool-org:
    api_token: bkua_hunter28265989387498729792378

A lot to take in? Read the Buildkite CLI documentation

The Buildkite SDK now supports C#, starting in v0.8.0. You can define and manage your Buildkite pipelines programmatically in C#, with the same type-safe experience available in the SDK's other supported languages: JavaScript/TypeScript, Python, Go, and Ruby. The package is now available for download from NuGet.

Several of our most popular plugins now support GCP and Azure, making it easier to use Buildkite with your preferred cloud provider.

The secrets plugin fetches secrets and injects them as environment variables into your builds. It now supports GCP Secret Manager and Azure Key Vault, in addition to Buildkite Secrets.

The cache plugin stores and restores build cache between pipeline runs. It now supports Google Cloud Storage and Azure Blob Storage backends alongside Amazon S3.

The docker-cache plugin speeds up Docker builds by caching images between pipeline runs. It now supports Azure Container Registry as a caching provider.

The docker-image-push plugin builds and pushes Docker images to Google Artifact Registry and Azure Container Registry alongside its existing support for Amazon ECR and Docker Hub.

(New) The azure-login plugin authenticates your Buildkite agents with Azure using managed identity or service principal credentials. Pair it with our secrets, docker-image-push, or cache plugins to streamline your Azure workflows.

You can now set an expiry date when creating an API access token. Once a token expires, any API requests using it will stop working, so forgotten tokens don't become a security risk.

Choose from preset durations (1 day, 7 days, 30 days, 90 days, 1 year), pick a custom date, or select "Never" to create a token with no expiry.

Key details

• Expiry is set at creation and cannot be changed afterward. To extend access, create a new token.
• You'll receive an email 3 days before a token expires, with a link to create a replacement.
• Expired tokens are automatically deleted after a grace period.
• All existing tokens are unaffected and continue to work with no expiry.

For more information, see the API access tokens documentation.

Test Engine Client (bktec) v2.1.0 introduces a new custom test runner and several improvements for pytest users.

🛠️ Custom test runner

You can now use bktec to split tests with any test runner that supports running specific test files via command-line arguments. For details, see the custom test runner documentation for Test Engine Client.

🐢 Split slow files by example (pytest)

You can now split slow test files by individual test examples when using pytest. This helps distribute long-running tests more evenly across agents and reduces build times.

🏷️ Tag filters (pytest)

The new --tag-filters option allows you to select and run tests based on a single key:value tag pair when using pytest.

Example:

bktec run --test-runner pytest --tag-filters "test.type:integration"

Read more about splitting slow files by example and tag filters in the Test Engine Client pytest documentation.

bktec v2.1.0 Release Notes.

You can now bring your CircleCI pipelines over to Buildkite even faster! Our pipeline conversion tool now supports more cases to convert CircleCI workflows to Buildkite pipelines. In addition to generating pipeline YAML that you can run, the output also includes information about required agent setup and other adjustments that may be needed to get a complete functional pipeline.

This makes it simple to:

• Copy an existing CircleCI pipeline
• Instantly see the equivalent Buildkite pipeline steps
• Speed up trying out Buildkite with less manual rewriting

👉 Try it out in the Pipeline Converter
📖 See the documentation

Steps that were canceled (either directly or as part of a canceled build) now return state: "canceled" in the REST API and webhooks, instead of state: "finished" with outcome: "errored".

Previously, canceled steps were grouped with timed-out and expired steps under the same errored outcome. This made it difficult to distinguish between steps that were manually canceled versus those that failed due to timeouts or system errors.

With this change:

• Canceled steps: state: "canceled", outcome: "neutral"
• Timed-out/expired steps: state: "finished", outcome: "errored"

If you have integrations that parse step state from webhooks or the REST API, update your logic to handle the new canceled state:

- if step.state == "finished" && step.outcome == "errored"
-   # Could be canceled, timed out, or expired
+ if step.state == "canceled"
+   # Step was canceled
+ elsif step.state == "finished" && step.outcome == "errored"
+   # Step timed out or expired

This affects step.finished webhook events and REST API endpoints that return step data.

You can now bring your GitHub Actions workflows over to Buildkite even faster! Our pipeline conversion tool now uses AI to translate Actions workflows to Buildkite pipelines. In addition to generating pipeline YAML that you can run, the output also includes information about required agent setup and other adjustments that may be needed to get a complete functional pipeline.

This makes it simple to:

• Copy an existing Actions workflow
• Instantly see the equivalent Buildkite pipeline steps
• Speed up trying out Buildkite with less manual rewriting

👉 Try it out in the Pipeline Converter
📖 See the documentation

You can now select multiple log lines by Shift+Clicking, making it easier to copy multiple lines or share a permalink to a line range.

Teams can now customize their suite summary view to better track the trends that matter most. Save default filters and show or hide metric charts to tailor the view to the suite insights you care about.

This makes it easier for your team to:

• Focus on the most relevant suite trends
• Reduce visual noise by hiding unused metrics
• Keep a consistent, shared view across your team

We're excited to announce that our Terraform module for the Elastic CI Stack for GCP is now in Preview! The included Terraform modules will enable you to deploy and manage autoscaling Buildkite agent clusters in GCP with ease.

This Terraform project supports the following basic features:

• Autoscaling based on agent utilization metrics
• Support for both Linux agents on both x86-64 and ARM64 architectures
• Built-in secrets management via GCP Secrets Manager

The module is currently in preview. If you encounter any issues or have feedback, please raise an issue on GitHub or reach out to support@buildkite.com.

Check out GCP Elastic CI Stack in our docs, the module's GitHub repository, and our example configurations to get started.

We've just released two new incident management plugins that allow you to integrate your Buildkite pipelines with PagerDuty and Incident.io.

PagerDuty plugin

The PagerDuty plugin can be configured to check the status of a single job, or an entire build. If the job or build fails, the plugin will create a PagerDuty incident of whatever severity you specify.

Incident.io plugin

The Incident.io plugin can be configured to check the status of a job. Like the PagerDuty plugin, it will create an incident if the job fails. The Incident.io plugin accepts any of the custom severity levels you may have defined in Incident.io, and can optionally fill out the incident name and summary for you, as well as specify whether the incident Slack channel should be public or private.

Follow the links above for complete usage information for each of these plugins. Have questions or need help? Reach out to us at support@buildkite.com.

We have released a new major version of the Buildkite test engine client (bktec). This version introduces dynamic parallelism, intended to accommodate builds where the number of tests run is variable, for example when predictive test selection is used.

From v2.0.0 bktec can dynamically set command step parallelism to achieve a specified target build duration.

📚 Learn more about bktec dynamic parallelism.

Note on upgrading to bktec v2.x.x sub-command support has been added in this release. Calling bktec without a sub-command is no longer supported, so when upgrading to v2.x.x please update your step definitions.

# < v2.0.0
command: bktec

# >= v2.0.0
command: bktec run

You can now toggle display properties in your test data tables. Turn on/off fields like State, Location, Repository, and Labels so you only surface the context that’s relevant to you and clear out any extra clutter.

Customizable display properties are available in:

1. The Tests tab for a build or a build's job
2. The Tests view and when viewing saved views in Test Engine
3. The single run view in Test Engine

Saved views have also been updated, allowing your selected display properties to be stored as part of the saved view configuration. This ensures your preferred layout is preserved and shared across your suite.

A common frustration when running in CI is that agent instances can become corrupted in such a way where they are no longer able to consistently run jobs. This can lead to retries failing, which can be difficult to diagnose and fix. Within Buildkite, by default, jobs are run on the agent that has most recently finished a job, which can lead to retries running on the same agent that failed the first time causing repeated failures.

With the new Retry Agent Affinity feature, you can control where your retries run. Retry agent affinity is set at the Cluster Queue level, and when set to prefer-different, will prefer to run retries on a different agent than the one that failed the first time. This can help to avoid retries failing due to repeated runs on the same corrupted agent.

To set the Retry Agent Affinity on a cluster queue, you can go into the Cluster Queue settings and select the Retry Agent Affinity option:

Alternatively, this value can be set via both the REST and graphQL APIs.

Availability

Retry agent affinity is available for all self-hosted cluster queues.

If your agents are using an acquire-job workflow such as agent-stack-k8s, the setting will have no effect, as Buildkite doesn't control job dispatch for these agents.

Retry agent affinity can't be set on hosted queues, as agents in hosted queues are ephemeral, and so retries will always run on different agents from the original job.

You can now detect and manage newly introduced tests with the New Test monitor in Test Engine Workflows!

The New Test monitor automatically detects newly introduced tests to your test suite. By triggering appropriate actions to track and validate the performance of new tests, you can proactively manage these new tests and ensure you're not introducing flaky tests into your test suite.

What's new

• Detect newly introduced tests in your test suite automatically
• Full workflow action support including labeling, state management, Slack notifications, and Linear issue tracking
• Tag-based filtering to trigger actions only for new tests with specific tags

Learn more about the New Test monitor in our documentation.

We're excited to announce that test executions can now be grouped by location and tag! Grouping executions makes it easier to compare related tests side-by-side, helping you quickly spot patterns, outliers, and performance differences. This is especially useful for teams that use tags to classify tests by component, owner, type, cloud provider, or any other custom metadata.

The new grouping functionality is available in three areas of the platform:

1. In the Tests tab for a build or a build's job (shown below)
2. In the Tests view and when viewing saved views in Test Engine
3. When viewing a particular run in Test Engine

If you're not currently collecting tag metadata for your test executions, read the docs to learn more.

We're excited to announce our Terraform module for the Elastic CI Stack for AWS is now in Preview!

For teams who prefer infrastructure-as-code with Terraform over CloudFormation, you can now deploy and manage your autoscaling Buildkite agent clusters using familiar Terraform workflows.

This Terraform module supports all the features available in our Elastic CI Stack for AWS:

• Autoscaling based on agent utilization metrics
• Support for both Linux and Windows agents
• Configurable spot and on-demand instances
• Built-in secrets management via S3 and AWS Secrets Manager
• Pipeline signing with KMS
• Scheduled scaling for cost optimization

The module is currently in preview. If you encounter any issues or have feedback, please raise an issue on GitHub or reach out to support@buildkite.com.

Check out Setup with Terraform in our docs, the module's GitHub repository, and our example configurations to get started.

For those who prefer CloudFormation, the Elastic CI Stack for AWS is also available as a CloudFormation Stack.