Changelog roundup: October '25

Welcome to another edition of the Changelog roundup, the ongoing series in which we check in periodically with the Buildkite Changelog and put together an easily digestible summary of all of the latest new features and improvements. 🪁

This month, we've got lots to share, spanning the full Buildkite platform:

• What's new in Test Engine: Introducing Test Engine workflows, better filtering and layout controls in the dashboard, and automated removal of the flaky test label
• What's new in Pipelines: First-class support for GitHub merge queues, plugin-free secrets in pipeline YAML, better controls for blocking and unblocking builds, in-page rendering of HTML artifacts, and XCode 26 on macOS hosted agents
• What's new in Package Registries: Native support for .NET packages with NuGet registries, Private Storage Link for Google Cloud Platform, and webhook notifications for package-creation events

What's new in Test Engine

Since our last episode, we've shipped a number of new features in Test Engine focused on more powerful workflows, more flexible filters and layouts, and more intelligent automation.

Introducing workflows

Test Engine now supports definable workflows that let you create mappings between the observations that Test Engine makes about your test suite and the actions you'd like to take in response to them.

With workflows, you can use multiple heuristics to identify and label your tests, change the state of a test (enabled, muted, skipped), send Slack notifications and webhooks, and integrate with external task-management applications like Linear to create issues that delegate follow-up work automatically.

Check out the release blog to learn more, or have a look at the intro below for a three-minute walkthrough:

Improved filtering and layout controls

A handful of new filtering capabilities in Test Engine let you filter by branch, state, result, owner, label, and tags. Metrics cards reflect your selected filters for high-level insights, and column selection is now consistent across the pages of Test Engine and Pipelines.

Automatic removal of the flaky label

The flaky test label is now removed automatically from tests that don't report as both failed and passed on the same commit SHA within 100 executions or seven days. This automated process ensures that your labels are more accurate, minimizes noise, and saves you from having to remove outdated labels yourself.

Learn more about flaky-test detection in the docs.

What's new in Pipelines

We also added a number of new features in Pipelines designed to help you ship faster, keep your pipeline code simpler, and have more control over pipeline operations and configurations.

Support for GitHub merge queues

Buildkite now has first-class support for GitHub merge queues, which let you opt into creating and canceling builds based on merge_group webhook events from GitHub. Merge-queue builds are identified clearly in the Buildkite UI, and pipeline behavior can be adjusted based on conditionals and environment variables that identify the build as belonging to a merge queue.

With this new integration, you can:

• Create builds when a merge group is added to the merge queue
• Cancel in-progress builds when a merge group becomes invalid
• Identify merge queue builds in the Buildkite UI
• Vary pipeline behavior for merge queue builds
• Skip unnecessary work using the if_changed attribute of a pipeline step

To learn more, check out the docs or the video below for a quick introduction:

Easier use of secrets in pipeline YAML

Buildkite secrets is an encrypted key-value store that allows you to manage sensitive data like API tokens and passwords for use in your pipelines. As of the latest release, we've got two new features to share: 

1. Direct integration in YAML steps. You can now load secrets directly into your jobs' environments using the new secrets key. For example:

   # Loaded into environment for all steps in the build
   secrets:
   - API_ACCESS_TOKEN
   
   steps:
   - command: scripts/deploy.sh
     # Loaded into environment for this step only
     secrets:
       - DEPLOY_KEY
       
   - command: scripts/lint.sh

2. Policy-based access control. With policies, you can configure access to secrets within a cluster based on the context of a build, from broad access (entire cluster) to specific conditions, such as particular pipelines, branches, or users. For example, to limit access from builds of the main branch to a given team on a given pipeline:

   - pipeline_slug: "my-pipeline"
     build_branch: "main"
     build_creator_team: "e2b7c3f4-1a5d-4e6b-9c8d-2f3a4b5c6d7e"

To learn more about YAML integration and policy-based access controls for secrets, see the secrets documentation.

Team permissions for block and input steps

You can now specify which teams are allowed to unblock a build or submit an input step using the allowed_teams field. With this new field, you can separate the permission to create a build from the permission to unblock a build, allowing you to create more flexible and secure delivery workflows.

For example, to allow only the members of the platform_engineering team to apply changes to production infrastructure with a block step:

steps:
  - label: "Plan"
    command: "terraform init && terraform plan -input=false -out=tfplan"
    plugins:
      - artifacts:
          upload: "tfplan"

  - block: "Apply changes?"
    allowed_teams: ["platform-engineering"]

  - label: "Apply"
    command: "terraform apply -input=false tfplan"
    plugins:
      - artifacts:
          download: "tfplan"

Or to allow only wizards to cast spells with an input step:

steps:
  - input: "🔮"
    allowed_teams: "wizards"
    fields:
      - text: "What spell would you like to cast?"
        key: "spell-of-the-day"

To learn more, see the docs for block steps and input steps.

More control over API access token creation

Buildkite organization administrators can now restrict non-admins from creating new API access tokens. This new security setting is available in the Security > API tab of your organization's Settings page. (Previously existing tokens are unaffected by changing this setting.)

To learn more about managing API access tokens, see the access tokens documentation.

Native support for HTML artifacts

Testing frameworks and code-coverage tools often generate rich HTML reports, but such reports can be cumbersome to download and navigate. Now, when you upload a collection of related HTML, CSS and JavaScript assets as a build artifact, we'll render them inline as an HTML widget, allowing you to drill into and navigate around them more easily.

To learn more, check out the Changelog post.

Xcode 26 in macOS hosted agents

We've also added the latest version of Xcode to our macOS hosted instances, which can be selected with macOS Sequoia (15.6.1) and Tahoe (26). You can set the Xcode version in the Base Image tab of your hosted agent's queue configuration page:

What's new in Package Registries

Finally, we've added several new features to Package Registries that expand our ecosystem coverage, give you greater control over where your packages are stored, and make it easier to integrate with third-party systems.

NuGet registries for .NET packages

Package Registries now support NuGet, the standard package manager for the .NET ecosystem. That means you can use Package Registries to manage any .NET package supported by NuGet — C#, F#, or VB.NET.

To learn more about creating and managing NuGet package registries with Buildkite, see the Package Registries documentation.

Private Storage Link for Google Cloud Platform

We've expanded our support for Private Storage Link — a feature that allows you to store your packages in your team's cloud object storage — to include Google Cloud Platform. Now, you can choose either Amazon S3 or Google Cloud Storage (GCS) when configuring your global and per-registry storage locations, giving you more flexibility to keep your packages within your security perimeter and close to the build runners that need them.

To learn more about setting up Private Storage Link with GCS, see the documentation.

Webhook notifications

Package Registries now supports outbound webhooks as well — configurable HTTP requests that are emitted whenever a new package is created. This particular building block can help you trigger more event-based flows in your software delivery lifecycle, such as triggering a vulnerability scan on a newly published package.

Webhooks are available for all supported ecosystems. See the webhooks documentation to learn more.

Wrapping up

That's all for now! We hope this latest round of updates makes your experience with Buildkite even more awesome. 🚀

Have thoughts? Questions? Ideas for further improvements? Drop us a line in the forum — and if you haven't already, be sure to bookmark the Changelog (or better, subscribe to the RSS feed) to keep up with all of our latest features, updates, and announcements.

Until next time! 👋