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.

We've added support for the latest Xcode 26 to our macOS instances, this can be selected with macOS Sequoia (15.6.1) and Tahoe (26).

We encourage everyone who has been testing the Xcode betas and release candidates to move to the release version.

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.

We've enhanced the Test Engine UI with new filtering capabilities and layout improvements. This bring improved flexibility to your ability to analyze test metrics.

Enhanced filtering throughout Test Engine

The new filter component has been uplifted to give you easier access to all relevant filters. You can now filter test executions by:

• Branch - Filter tests that were executed on a specific branch
• State - Filter tests that are muted or skipped
• Result - Filter test executions by passed or failed result
• Owner - Filter tests owned by specific teams
• Label - Filter tests that have specific labels
• Tags - Filter test executions with specific set of tags

These filters are now available across:

• Suite Summary page
• Run details page
• Test details page
• Pipeline build page

Smarter metric insights

Metric cards in the Suite Summary, Run details, and Test details pages now reflect your selected filters, giving you instant insights into metrics for the tests that matter most.

Consistent column selection

We've brought the layout from the Tests page to the Run details page and Pipeline build page. You can now select which columns to display in the test results table, making it easier to focus on the information that matters most to you.

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.

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.