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.

We're excited to share that Test Engine has rolled out a new and improved way to manage flaky tests! Utilizing customizable columns we have moved flaky tests into a new saved view.

This change gives you power to customize the views that matter most to you. 🚀

What's New

"Flaky" Saved View:

View all actively flaky tests in one place. Flaky tests are now clearly labeled, making it easier to filter and manage them at a glance.

Remove the Flaky Label:

If you've fixed a flaky test, simply remove the flaky label from its test page. This automatically updates your Flaky saved view.

Team-Based Filtering:

Use the new Ownership filter to view all tests owned by your team(s). You can save this view for quick access anytime.

You can now customize which metrics are displayed in the Tests View to better suit your needs. We've added new metrics to provide deeper insights into your test performance to help you make more informed decisions about your tests.

Available metrics

1. Reliability
   The reliability of the test within the selected date range and filters. Calculated as the percentage of 'passed' executions out of all 'passed' and 'failed' executions.

2. Average duration
   The average time taken to execute the test within the selected date range and filters.

3. Executions 🆕
   The number of times the test was executed within the selected date range and filters, grouped by result.

4. Total duration 🆕
   The cumulative time spent on all test executions within the selected date range and filters.

5. Passed on retry 🆕
   The number of times the test reported both 'failed' and 'passed' results on the same commit SHA within the selected date range and filters.

6. Latest passed on retry 🆕
   The most recent occurrence where the test reported both 'failed' and 'passed' results on the same commit SHA within the selected date range and filters.

Saving the customizations

Building on top of our Saved views, you can also save your customizations to tailor the view to your specific workflow.

We're excited to announce Vitest support for our Buildkite JavaScript Test Collector, expanding our test framework coverage for Test Engine.

With Vitest support in the JavaScript Test Collector, you can now:

• Collect test results from your Vitest test suites
• Track test performance and flakiness over time
• Benefit from Test Engine's powerful analytics and insights
• Automatically quarantine flaky tests

To begin using the Test Engine with Vitest, follow the instructions in our JavaScript Test Collector documentation.

We've added support for GitLab.com commit statuses to Buildkite Pipelines ✅

Buildkite can now send status updates to GitLab for each build state (scheduled, started, running, passed, failed, blocked, canceled, skipped). Status updates appear on commits and merge requests in GitLab. These link back to the corresponding Buildkite builds.

Turn this on today by connecting to GitLab.com:

Then update your favorite pipeline's repository settings page to turn on commit status reporting ✨

For more details, see our GitLab documentation.

You can now send Slack notifications from Buildkite Test Engine!

Slack notifications can be triggered when a test state changes, or when a test label is added or removed.

Additionally Slack notifications can be filtered to only tests owned by particular teams.

Read more about Test Engine Slack notifications.

You can now send webhooks from Buildkite Test Engine!

Webhooks can be triggered by the following events:

• Test state changed
• Test label added or removed

Additionally webhook events can be filtered to only tests owned by particular teams.

Read more about Test Engine webhooks.

You can now save your favorite test filters in Test Engine for quick access.

The new filter bar in the test list lets you add filters using execution tags and test labels. Once you've set up a view you like, click Save to name it. Your saved filters will then appear as a view in your suite navigation for easy access.

Buildkite Portals are user-defined GraphQL operations exposed via authenticated URL endpoints — offering a new, secure way to access the Buildkite API.

Designed with machine-to-machine operations in mind, Portals are not tied to user-owned access tokens. Instead, they use ephemeral, scoped tokens that can only perform the operations defined in an approved GraphQL document.

Key benefits of Portals include:

• Scoped access — Tokens are restricted to the exact operations defined by organization admins. This enables fine-grained, least-privilege access to your Buildkite data.
• Ephemeral tokens — Tokens are short-lived and single-purpose, ideal for secure machine-to-machine communication.
• User-invoked flow — Optional interactive flows allow users to generate tokens on-demand, similar to OAuth.
• Userless authentication — Tokens are not tied to any individual user, avoiding disruptions if team members are removed.

Getting started with Portals

Portals can be created by administrators from organization settings page. Each portal is assigned a unique endpoint with the following URL structure: https://portal.buildkite.com/organizations/{organization.slug}/portals/{portal.slug}

Portals support passing variables to enable dynamic operations and offer multiple authentication mechanisms for flexibility and security.

For more information, see the Portals documentation.

Buildkite Test Engine now supports test splitting (smart bin packing for faster CI) and auto-quarantining (automatic detection and isolation of failing tests) for Python PyTest suites.

• ✅ Cut down your critical path time.
• ✅ Keep flaky tests from blocking your pipeline.
• ✅ Spend less time on manual triage.

To get started, install the Test Engine Client to:

• Automatically split tests evenly across parallel jobs.
• Quarantine unstable tests based on customizable heuristics.

For full setup instructions, see the Test Engine docs.

You can now label your tests with Buildkite Test Engine!

Labels allow you to:

• Organize tests to be more meaningful to your team and organization.
• Categorize tests, and therefore, can be used to filter tests within Test Engine.

Labels may be applied to or removed from tests:

• Manually through the Buildkite interface.
• Automatically through the automatic quarantine or test execution tags features.
• Using the REST API.

Start labelling your tests with Test Engine today.

You can now add custom tags to your tests — unlocking a whole new dimension (literally) of insight and control.

Whether you want to tag tests by the infrastructure they run on, the services they touch, or framework versions they depend on, custom tags let you define what matters — and then slice your test data by those attributes.

🔍 Find root causes faster

Spot patterns in failures and slowdowns by breaking down your suite along your real-world dimensions — like container image, compute pool, or dependency version.

📊 Insights tailored to your stack

Move beyond generic test metrics. Aggregations by custom tags give you visibility into the things that actually cause pain in your CI.

💸 Drive cost and performance optimizations

Use tags to identify high-cost, slow, or flaky tests by environment — and target improvements where they’ll have the biggest impact.

Start tagging your tests with Test Engine today.

Buildkite has joined the the GitHub Secret Scanning Program to enhance security for your API tokens. This program helps detect and alert us when a Buildkite API access token is leaked in a public GitHub repository.

What happens when a token is detected:

• For tokens found in public repositories or npm packages: GitHub immediately notifies Buildkite, and we automatically revoke the affected token to prevent unauthorized access. The token owner and organization admins receive notifications about the incident.
• For tokens found in private repositories with secret scanning enabled: Repository admins and the committer are alerted directly through GitHub's interface, where they can view and manage the detected secrets.

FAQ's

Do I need to enable anything to get this protection?

• For public repositories, protection is automatic with no configuration needed.
• For private repositories, repository administrators need to enable GitHub Secret Scanning.

What types of Buildkite tokens are protected?

• Currently, only Buildkite API access tokens

How will I be notified if my token is revoked?

• The owner of the token and the admins of the associated organization will receive an email from Buildkite.

What should I do if I receive a notification about a leaked token?

• Generate a new access token for your Buildkite user account.

It is now possible to pause individual Buildkite agents. Pausing an agent is similar to stopping an agent, but unlike stopping, a paused agent remains running and can resume work later on.

Pausing an agent is a useful alternative to stopping an agent, especially when resources are tied to the lifetime of the agent, such as a cloud instance configured to terminate when the agent exits. By pausing an agent, you can investigate problems in its environment more easily, without the worry of jobs being dispatched to it.

Some examples of maintenance operations that could benefit from pausing an agent include:

• pruning Docker caches
• emptying temporary directories
• updating code mirrors
• installing software updates
• compacting or vacuuming databases

You can pause agents in either the UI, GraphQL API or Rest API. Paused agent counts will be reflected in the platform.

To fully benefit from pausing, we recommend upgrading your agents to the latest released version.

See Pausing and resuming agents on Buildkite Docs for more information.

Buildkite now supports setting commit statuses on GitLab self-managed instances. This integration enables real-time status visibility in merge requests and can block merging until builds pass.

You can configure commit statuses today from your organization's repository providers page:

https://buildkite.com/organizations/-/repository-providers

Look under API Settings for configuration instructions:

Then go to your favorite pipeline's repository settings page to turn on commit status reporting ✨