Buildkite

Buildkite Cache is now generally available on hosted and self-hosted agents, letting jobs reuse prior work such as dependency downloads or entire build commands via buildkite-agent cache restore, save, and exec commands. Cache registries now have policies scoped by pipeline, branch, and build with CEL conditions, letting platform teams control which builds can write to shared cache entries so untrusted forks cannot poison caches used by main and release builds.

Matters for: Platform and build engineering teams running CI pipelines with self-hosted agents backed by Amazon S3 or S3-compatible storage, especially those accepting pull requests from external forks.

The Buildkite MCP Server now includes validate_pipeline, a read-only tool that checks pipeline YAML syntax and structure against Buildkite's pipeline schema without uploading the pipeline or starting a build, returning validation errors with paths and messages so an AI agent can fix invalid step definitions and schema errors. It does not validate environment variable interpolation, plugin configuration, dependency references, or dynamically generated steps, so these must still be checked another way; it requires Buildkite MCP Server v1.23.0 or later with the pipelines toolset enabled.

Matters for: Teams using AI coding agents to generate or edit Buildkite pipeline YAML before committing changes.

The Buildkite MCP Server adds tools so an agent can compare a failed build against the last passing one, retry only infrastructure-caused job failures while leaving real test failures alone, surface a build's slowest test executions, attach a missing GitHub webhook to a pipeline, manage Buildkite Cache registries, and check a GitHub App connection's API quota. These tools are available in both the open-source and Remote MCP Server, with GitHub quota tools requiring organization administrator access and Remote MCP Server users needing to sign in again to grant the new permissions.

Matters for: This matters for teams whose pipelines depend on GitHub webhooks and a connected GitHub App's rate-limited API, and for teams running large test suites through Buildkite Test Engine or using the public-preview Buildkite Cache registries.

Buildkite now offers a public preview of Buildkite Cache, letting pipelines save and restore files and directories across jobs and builds via cache.yml definitions and buildkite-agent cache restore/save commands to avoid regenerating package downloads, compiled dependencies, and similar data. This is a new opt-in capability with no breaking changes, though it requires clustered agents on Buildkite agent version 4.0.3 or later and, for self-hosted agents, configuration of your own S3 or S3-compatible storage.

Matters for: Relevant for teams running self-hosted Buildkite agents on their own AWS infrastructure who want to reduce build times for dependency-heavy pipelines.

A new Buildkite VS Code extension lets you browse and manage pipelines, view agent status, stream job logs, get build notifications, and validate pipeline YAML without leaving the editor. This is a new capability, not a breaking change, and is installed from the VS Code Marketplace.

Matters for: This matters for engineers running Buildkite pipelines who use VS Code as their primary editor and want to monitor builds and agents without switching to a browser.

Buildkite Agent v4 is now delivered to installations and upgrades on the latest or stable channels, removing functionality that had been deprecated over the eight years since v3 shipped in 2018 and making current supported behaviour the default. This is a breaking change for pipelines relying on deprecated behaviour, plugins, or hooks, so affected users must consult the v3 to v4 upgrade guide, and can stay on v3 by pinning their agent version or switching to the oldstable channel.

Matters for: Relevant to teams running self-hosted or hosted Buildkite agents whose pipelines depend on custom plugins or hooks that may rely on deprecated agent behaviour.