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.

The flaky label is now automatically removed from a test if it doesn't report both failed and passed results on the same commit SHA within 100 executions or 7 days. This keeps your labels accurate, reduces noise, and saves you from having to manually remove outdated flaky labels yourself.

Learn more about flaky test management.

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.

More than 92% of Agent requests now communicate with isolated API servers, reducing the impact of database incidents and protecting them from noisy neighbours. This was part of a commitment we made in January to improve our resilience.

While the vast majority of requests are now isolated, there are some actions you need to take to fully leverage these changes.

• Rotate your Agent Registration tokens
  • This includes tokens used for metrics collection or by recent versions of the Kubernetes stack (v0.28.0 onwards)
• Ensure you’re running at least version v3.97.0 of the agent

Together, these will ensure all traffic between your agents and our backend is routed to isolated API servers.

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.

We've updated the names of our GitHub apps to make their purpose clearer and help you choose the right integration for your needs.

Name changes:

• "GitHub" → "GitHub (Limited Access)"
• "GitHub (with code access)" → "GitHub"

What each app does:

GitHub (formerly "GitHub (with code access)") is now the default option. This app can:

• Clone your repositories during builds
• Access your source code for hosted agents

GitHub (Limited Access) (formerly "GitHub") provides basic integration without code access:

• Trigger builds on commits and pull requests
• Update commit statuses and checks
• Perfect for scenarios where you don't need Buildkite to access your source code

These updates improve clarity around each app's capabilities.

Learn more:

• Setting up GitHub integration
• Understanding code access for hosted agents
• Migrating between GitHub apps

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.

All macOS workloads on Buildkite hosted agents have recently been upgraded to run on Apple’s latest M4 Pro generation hardware - delivering better price-performance for your CI builds.

The M4 Pro chip delivers meaningful improvements over the previous generation (M2 Pro), including:

• Up to 30-45 % faster CPU performance in real-world Xcode builds and test runs
• Next-generation GPU architecture for smoother UI testing and graphics-heavy tasks
• Higher memory bandwidth for faster access to large codebases and build artifacts

Starting today, we’ve updated our Mac shapes with two new M4-optimized options:

• Medium (6x28)
• Large (12x56)

These new shapes supersede the legacy M2-based shapes, which will be deprecated on July 31. Customers are advised to update any existing queues to use the new M4 shapes ahead of time to avoid disruption.

• Enterprise customers: Your account team will reach out to support this transition.
• Pro customers: You’ll receive an email shortly with more details and instructions for updating existing queues.

Have questions or need help? Reach out to us at support@buildkite.com

With super fast startup times, clean ephemeral environments for each job, the latest Xcode updates and developer tools ready to go - and now powered by M4 Pro - Buildkite Hosted Agents for macOS are built for fast, reliable CI at scale.

Over the past few months, we’ve made a series of improvements to the Buildkite Agent Stack for Kubernetes, focused on simpler setup, improved efficiency, and reliable scaling. Bringing us to version 0.29.2, these updates are the result of our sustained engineering investment in our Kubernetes integration, designed to help platform teams reduce overheads and ship faster with greater confidence.

What’s improved

• Simpler setup: You can now deploy a stack with just a single cluster-scoped agent token. Previously-required configuration is no longer required: the GraphQL token, organization slug, and cluster UUID are no longer required or used. Default queue behavior is also streamlined: the stack now defaults to the cluster's default queue, rather than a queue called kubernetes.
• Better scaling under load: The internals of the controller have been reworked to more efficiently discover and handle large volumes of jobs, even in high-concurrency environments. Job environment variables are now passed between job containers directly, reducing per-job Kubernetes object sizes. Fixes to tag matching and queue routing ensure that job lifecycles are handled correctly by the controller.
• More secure by default: GraphQL tokens, which have many capabilities that are unnecessary for running a stack, are no longer used. Everything now runs on the REST API using scoped agent tokens, and we’ve started internal testing of scoped secret support for more secure isolation across pipelines and environments.
• Greater configurability: Helm chart values now expose settings for things like job name prefixes, controller env vars, resource limits, and pod annotations, giving teams more flexibility to tune the stack for their environment with out-of-the-box controls.
• Better errors and observability: Error messages for Kubernetes job creation failures now include the job spec in YAML form, making it easier to diagnose misconfigurations. Prometheus metrics have been updated to support monitoring stack performance. Stack-level job failures are now reported to Buildkite using a new stack_error signal reason.

Recent releases

These improvements have been rolling out since March, with highlights in the following versions:

• v0.29.2: Fixes a permissions issue within job pods, upgrades Buildkite Agent to v3.100.1.
• v0.29.0: Introduces cluster-only agent support, removes the queue=kubernetes default tag, adds better error output and tag matching logic.
• v0.26.0 through v0.28.2: Improvements to cleanup, resource management, default queue handling, plugin mounts, GraphQL removal, and REST-only job fetch.

If you're running the Buildkite Agent Stack for Kubernetes, now’s a great time to upgrade. These changes simplify how you manage agents, reduce the number of moving parts, and make builds more predictable at scale. To get started, check out the official documentation.

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.

The new build page has been updated with a bunch of improvements that now make it easier to focus on what matters, move faster through your builds, and tailor the interface to suit how you work. Whether you're reviewing a failed test, scanning logs, or debugging pipeline performance, these updates help streamline the experience across pipelines of all shapes and sizes.

With so many changes landing, we thought why not record a video to walk you through them all.

Key changes

New build header

We've redesigned the build header into a more condensed version—reducing noise on the page, and helping to draw more attention to the things that need actioning: failed steps and annotations. With this revision, the build status is also now always visible regardless of how you've configured the build interface.

Overview tab

There's a new overview tab that contains high-level build information—such as the commit message, build creator, build trigger and much more.

Annotations tab

The annotations have been moved into a top-level tab, making them easier to find and use.

Configurable default view preferences

You can now set a personal default view preference—allowing you to control where you start when opening a build. This can be applied globally or customized per pipeline.

Collapsible sidebar

The sidebar can now be toggled open or closed, giving you more control over the layout when diving into a job or viewing other parts of the build.

Step search in the sidebar

We've added a new search, allowing you to find and jump to steps quickly across your build.

Keyboard shortcuts:

• S: Open search box
• Enter: Open the step
• Shift+Enter: Focus on step in current step view

Jump to failure

The jump to failure action has moved into the sidebar, making it possible to cycle through failures wherever you are in the build.

Other notable improvements

• Log performance: Improved rendering performance and added support for searching within collapsed sections.
• Canvas unblock UX: Clicking an unblock step now opens the unblock dialog directly.
• Smarter canvas focus: For large pipelines that don't fit neatly on the canvas, we now focus on the first failure—or the first step if all steps pass.
• Canvas zoom constraints: Zoom levels are now constrained to prevent unreadable dependency graphs.
• Resizable table columns: Table view now supports column resizing for improved readability of long job labels.
• Responsive improvements: Improved layout behavior on smaller screens to avoid overlaps and horizontal scrolling.

Thanks again for all the feedback which continues to help us shape each release.

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.

The Flaky Resolution feature is being deprecated and will be removed for all users in the coming week.

You can continue managing flaky tests by removing the flaky label. You can review all currently flaky tests via the Tests page, by filtering for tests with the flaky label.

Learn more about flaky test management.

The My Assignments feature is being deprecated and will be removed for all users in the coming week.

Users can continue to review tests owned by their teams using the filtering functionality on the Tests and Flaky tests pages.

As part of this change, the Flaky Summary Mailer will also be updated to show the flakiest tests owned by your team, rather than those that were previously assigned.

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.