Buildkite Introduces Scoped Secrets and Enhanced CI Tools
Continuous integration provider Buildkite has rolled out pipeline-scoped secrets and new Model Context Protocol tools aimed at validating pipelines, diagnosing failed builds, and repairing webhooks. Additionally, the company has introduced Linux arm64 support for its GitHub Actions compatibility layer and enhanced OpenTelemetry data in Buildkite Agent v4.1.0.
The new secrets view, found under Pipeline settings, allows engineers to create cluster secrets restricted to the current pipeline. This approach eliminates the need to manage every secret through the broader cluster interface. Teams can set conditions based on branch, queue, build source, or build creator, ensuring that secret values remain hidden after creation.
Matt Mejia, in Buildkite’s announcement, noted that this change “keeps pipeline-specific secrets together” while displaying the total number of secrets managed by the cluster. Users must have permission to edit the pipeline and manage its cluster. GitHub Actions pipelines will also prompt users to configure secrets before their first workflow runs.
“Pipeline secrets are cluster secrets restricted to the current pipeline, and branch, queue, build source, or creator conditions narrow access further.”
Matt Mejia
The Buildkite CLI has added a command for migrating GitHub Actions secrets. Version 3.59.1 addresses issues with handling relative workflow paths during migration. Agent v4.0.9 also ensures that Buildkite tokens are redacted by prefix in job logs, while v4.0.8 redacts captured job errors using registered secrets.
This update addresses various scenarios where credentials could be exposed or misconfigured, although scoped storage does not eliminate the need for careful control of their use within steps. InfoQ reported in 2025 that HashiCorp was promoting prevention-first secret management across developer tools and CI/CD systems. Buildkite’s documentation advises teams to expose secrets only to the steps that require them.
New Tools for Pipeline Management
The most significant feature changes are in Buildkite’s open-source MCP server. The new validate_pipeline tool allows users to check pipeline YAML syntax and structure against Buildkite’s official schema without uploading or starting a build. It provides paths and error messages that an AI coding agent can use to correct invalid steps, although it does not cover environment variable interpolation, plugin configuration, dependency references, or dynamically generated steps.
Another tool, compare_builds, enables users to compare a failed build with the most recent successful build on the same branch or another selected build. It reports steps that have newly failed, recovered, or remained broken, along with changes in runtime and retries. For up to three newly failing steps, it includes the end of the job log to provide immediate diagnostic context.
“Log access alone does not debug a build.”
Matt Mejia
The MCP release also adds Test Engine execution traces and slowest-execution queries. The create_pipeline_webhook tool can add a missing GitHub webhook to an existing pipeline, eliminating the need to recreate it. Version 1.23.0 modified create_pipeline to require callers to specify create_webhook, which is a breaking change.
Buildkite has reverted an earlier default; failure summaries now include jobs that never ran, as making this behavior optional led to extra tool calls by agents. Remote MCP connections can now be pinned to one Buildkite organization by adding it to the server URL, applicable to both toolset and read-only URLs.
Enhanced Compatibility and Telemetry
Providing agents with discrete validation, comparison, and repair tools should decrease their dependence on parsing full logs and composing lower-level API calls. Permissions remain crucial, as webhook repair and pipeline creation can alter CI configurations. InfoQ’s coverage of GitHub agentic workflows outlines a related security model based on isolated execution, restricted permissions, and auditable actions.
Buildkite’s GitHub Actions compatibility layer can now run its importer and generated jobs on Linux arm64 agents. Labels like ubuntu-24.04-arm require explicit queue mapping and do not default to x86-64 or emulation. This feature allows organizations with arm64 CI fleets to maintain that architecture when integrating compatible Actions workflows into Buildkite.
Other compatibility fixes address environment values, named secrets, runtime variables, and matrix values in service-container configurations. Buildkite has also made more strategy.* values available to job and step expressions. The changed-file limit for path filters has increased from 300 to 3,000, along with a fix for push workflows where a branch moved after the original push.
Agent v4.1.0 introduces cache save and restore durations and sizes to Buildkite telemetry. OpenTelemetry job spans now include the commit, pull request, and build author, providing context for teams investigating slow jobs or retry patterns. Pinterest previously described using Honeycomb with Buildkite to differentiate agent waiting time from script execution and identify jobs contributing to build-time spikes.
The associated Elastic CI Stack v7 release brings Agent v4 to Linux and Windows instances on AWS. It removes support for Agent v3 and retires or replaces some tracing and cancellation parameters. Buildkite advises users to review custom parameter files, deployment automation, and values supplied through AgentEnvFileUrl before upgrading. Support for all Agent v3 releases will end on 3 September 2027.
Source: InfoQ