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.

Running golangci-lint is now even simpler, with the release of the golangci-lint plugin for linting and formating Go code in your CI/CD pipeline.

The plugin makes it easy to integrate Go code quality checks into your Buildkite pipelines with minimal configuration. It runs golangci-lint using Docker by default, but can also use a local binary if preferred.

Basic usage

Add the plugin to your pipeline with minimal configuration:

steps:
  - label: "Go Lint"
    plugins:
      - golangci-lint#v1.0.0: ~

For complete documentation and all available options, see the golangci-lint plugin.

We're happy to announce that we have developed three new plugins that enable easy deployments and rollbacks using several popular code deployment tools.

The AWS Lambda Deploy plugin supports AWS Lambda deployments and rollbacks. It can deploy both zip files and container images, and uses aliases to enable blue/green deployments. Optional features include automatic rollback in case of failure, and a customizable health check for verifying the deployment. The plugin will also create detailed build annotations about the deployment and rollback process, for post-build review.

The ArgoCD Deployment plugin supports ArgoCD deployments and rollbacks. It leverages the ArgoCD API to perform health checks after the deployment is complete, and collects application and pod logs to upload as build artifacts for later review. It also includes support for sending your team Slack notifications when appropriate, as well as customizable manual rollback workflows.

The Deployment Helm Chart plugin supports simple deployments and rollback workflows using Helm. Specify your chart, release name, namespace, and optional values, and the plugin will take care of the rest. Rollbacks can be triggered by a user after manual application health checks.

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

You can now bring your Jenkins pipelines over to Buildkite even faster! Our migrate tool now supports pasting in your declarative or Groovy Jenkinsfile and will automatically translate it into Buildkite steps.

This makes it simple to:

• Copy an existing Jenkins pipeline
• Instantly see the equivalent Buildkite pipeline steps
• Speed up migrations with less manual rewriting

👉 Try it out in the Migrate Tool
📖 See the documentation

Organization admins can now restrict organization members from creating new API access tokens, providing better control over API access management across your organization.

This new security setting is available in the Security > API tab of your organization settings. When enabled, only organization administrators will be able to create new API access tokens for the organization.

Key details

• Existing tokens remain functional: All previously created tokens continue to work as expected. This setting only affects the creation of new tokens.
• Admin exemption: Organization administrators can always create tokens, regardless of this setting.

For more information about API access tokens, see the API access tokens documentation.

Buildkite now has built-in support for GitHub merge queues. You can now opt into creating and canceling builds based on merge_group webhook events from GitHub. These builds are identified as merge queue builds in the Buildkite UI, and build behavior can be customized based on merge queue-specific attributes.

🆕 What’s new

• Create builds when a merge group is added to the merge queue: Rather than rely on triggering a build based on unique gh-readonly-queue/* branches, builds can now be triggered in response to a merge_group webhook event.
• Optionally cancel in-progress builds when a merge group becomes invalid: Cancel any running builds belonging to a destroyed merge group (e.g. when the merge queue entry is replaced due to a pull request being removed from the queue).
• Identify merge queue builds in the Buildkite UI: Merge queue builds are listed separately at the top of the pipeline page, and builds can be filtered by the merge queue they belong to.
• Vary pipeline behavior for merge queue builds: Utilize new build conditionals (build.merge_queue.base_commit, build.merge_queue.base_branch) and environment variables (BUILDKITE_MERGE_QUEUE_BASE_COMMIT, BUILDKITE_MERGE_QUEUE_BASE_BRANCH) to modify the behavior of your pipeline.
• Avoid redundant work using if_changed during step uploads: For appropriate merge queue configurations, the agent if_changed attribute can use BUILDKITE_MERGE_QUEUE_BASE_COMMIT to determine which steps to run based on the contents of the pull request – particularly useful for monorepos.

For full details about these features and the interaction between GitHub merge queues and Buildkite see our tutorial or watch the video below:

We are excited to share the latest security and usability improvements we have made to Buildkite secrets, a secure key-value store for managing sensitive data across your pipelines.

Direct integration into YAML steps

While you can still access secrets through the buildkite-agent secret get command, we have now introduced the ability to load secrets directly into your jobs' environment using a new secrets key in your pipeline YAML.

# 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

In order to reference Buildkite secrets via pipeline YAML, buildkite-agent v3.106.0 or later is required.

Policy-based access control

Policies let you restrict secret access within a cluster based on the context of a build - from broad access from an entire cluster to specific conditions like particular pipelines, branches, or users.

For example, to only allow access from main builds from a chosen team on a given pipeline:

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

For the full list of claims and further examples, see the secrets documentation.

We’re excited to introduce a new feature in Test Engine: Workflows!

Workflows surface qualitative insights about your test suite that can be hard to extract from raw execution data alone. They let you create custom mappings between the observations Test Engine makes about your tests and the actions you want to take in response. With workflows, teams can streamline their testing process, detect flaky tests with greater precision, and boost productivity through automation.

🆕 What’s new

• Detect flaky tests with multiple heuristics: Identify unreliable tests with three detection models — passed on retry, transition count, and probabilistic flakiness score.
• Fine-grained control: Create separate workflows for different test types, teams, or environments to match the way your organization works.
• Customizable test management: Turn flaky test detection into immediate actions. Automatically label tests and change test states.
• Notifications: Send notifications about flaky tests via webhooks and Slack. Enrich Slack messages with test metadata.
• Issue tracking: Manage the resolution of flaky tests by integrating with your external issue tracker, and track its progress.
• Linear integration: Automatically create Linear issues for flaky tests. All issues appear directly in the test view for easy tracking and follow-up.

How to get started

Workflows are included in Test Engine and available to try today. Customers on Pro and Enterprise tiers can currently use up to 3 workflows per suite.

Watch the demo or read the docs to learn more.

Happy testing!

We've expanded Private Storage Link (PSL) to support storing packages on Google Cloud Platform (GCP). Customers can now choose either AWS S3 or GCS when configuring global and per-registry storage locations.

CI tools such as code coverage checks often generate reports in html format allowing developers to see a visual representation of metrics and drill down into specific areas of the code base. These tools often reference assets such as style sheets and javascript files, loaded via relative links. Unfortunately, due to how we authorize access to artifacts, loading these files wouldn't work, resulting in a poorly formatted report with broken links.

Now when you click on an html artifact we authorize access to all artifacts for that job, allowing you to easily use and navigate reports.

Announcing NuGet as the next supported ecosystem in Buildkite Package Registries

This allows you to use Buildkite as your registry for .NET packages, fully compatible with the latest v3 NuGet server specification

We have added webhook notifications for package registries.

These provide the ability to fire webhook notifications whenever a new package gets created in a registry.

This building block can help trigger more event-based flows in software delivery, for instance triggering vulnerability scanners to run over every newly published package.

Available now for all supported ecosystems in Buildkite Package Registries. To get started checkout our webhook documentation.

Following on from our GitHub app rename, we’ve updated the GitHub app used for user authentication with Buildkite.

This will only affect new signups and users that have previously authenticated using GitHub, as you’ll now be prompted to re-authorize.

No additional permissions are being requested and this will have no impact on existing repository providers connected to your organization or GitHub SSO authentication.

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 access control policies.

For example, you may want to allow all engineers to create a build in your infrastructure pipeline, but only allow your platform engineering team to apply the changes:

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"

The allowed_teams field is also available on input steps:

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

For more information, see the documentation for block steps and input steps.

You can now explore Buildkite with a library of live, working example pipelines! No setup or sign-up required. It’s the fastest way to see what Buildkite can do, and start building with confidence.

🆕 Public example pipelines are:

• Fully interactive and backed by real GitHub repos
• Searchable on the Examples Gallery
• Integrated directly into the pipeline creation form
• Embedded in the YAML steps editor as inline inspiration
• Always fresh, thanks to scheduled builds and Algolia-powered syncing

🔥 Why it matters

Starting from scratch in Buildkite used to be like opening a blank cookbook - you had the ingredients, but no idea how to bring them together. Now with real-world examples, you get the full recipe in action! You can explore pipelines that run in real time, show actual build logs, and are easy to fork and modify.

These examples span a wide range of use cases, including:

• 💻 Multiple languages and frameworks
• 🔄 Dynamic Pipelines
• 🐳 Docker builds
• 🏛️ Monorepo patterns
• 🚦 Concurrency groups
• 🛑 Block steps
• 🪝 Custom hooks

...and many more!

Whether you’re evaluating Buildkite, onboarding a team, or looking for inspiration, examples give you a fast, safe way to explore what’s possible.

• ✅ It’s onboarding without the guesswork
• ✅ It’s demos without the setup
• ✅ It’s Buildkite unboxed

🪄 See Example Pipelines in Action

Examples Gallery

Explore the new Examples Gallery, browse the public GitHub repos, and see real pipelines running live on Buildkite.

Examples in Product

This walkthrough shows how easy it is to go from creating a new org to running your first build using examples directly in onboarding, pipeline creation, and the YAML steps editor.

🆕 Available to try out!

• Browse the Examples Gallery
• See our live Public Pipelines on Buildkite
• See our Example Repositories

This feature is now live for all users 🚀

Got an idea for a new example? Let us know or contribute on GitHub.