← Back to all sparks
B

Buildkite

INFRA · APIS
Velocity8.8

Buildkite is rebuilding CI for agents: headless APIs, MCP tools, failure you can act on early.

headless-cimcpagent-nativeobservabilitytest-engineapi-coverage
Current state
Buildkite is shipping in two directions at once, and both point at automation as the consumer. On the agent side: an MCP server that now waits on builds and summarizes failures in one call, plus broad new REST and GraphQL coverage for pipeline creation, org administration, notification services, hosted agents, and artifacts. On the pipeline side: a checkout block in pipeline YAML that absorbs what previously took Sparse Checkout, Custom Checkout, and Skip Checkout plugins, Test Engine metrics for reliability and duration behind a dated version header, and job logs exportable to an OpenTelemetry collector. Agent v4 becomes stable on 1 September.
Where it's heading
The organizing idea is headless CI — every operation that used to require the web UI becoming callable, and every failure becoming legible to something that is not a human reading a log. Promise job failure is the sharpest expression of it: the build lifecycle itself is being reshaped so remediation can start before a job finishes. The versioned API header and the v3-to-v4 stable transition suggest Buildkite is settling its interfaces deliberately rather than accreting them, which is what you do before you expect programmatic clients to depend on them.
Prediction
Expect the MCP server to keep collapsing multi-call workflows into purpose-built tools the way get_build_failure_summary and wait_for_build did, and expect promise-based signalling to extend past failure to other states a long-running job can predict.

Recent moves

  1. 5d ago

    Analyze test reliability and performance with the Test Engine API

    The Test Engine list-tests endpoint returns aggregated reliability, duration, and execution metrics with filtering, sorting, and pagination, opted into via a Buildkite-Version header. Flaky-test triage becomes a query rather than an export, and the dated header keeps existing integrations untouched.

  2. 5d ago

    Customize Git checkout behavior directly in pipeline YAML

    A checkout block in pipeline YAML now handles shallow clones, sparse paths, submodules, custom Git flags, and skipping checkout entirely, settable per pipeline or per step. It folds three separate community plugins into first-party configuration — the same consolidation instinct visible across this batch, applied to the pipeline definition.

  3. 6d ago

    Start fixing builds before failing jobs finish

    ⚡ SPARK

    Promise job failure lets a running job declare its expected exit status before it finishes, so Buildkite applies retry and soft-fail rules and marks the build failing immediately while the job runs on. It is the batch's structural change: the build lifecycle is reshaped so remediation can begin during the job rather than after it.

  4. 6d ago

    Send job logs to your OpenTelemetry collector

    Agent v3.135.0 can ship job logs to an OpenTelemetry collector, correlated with job, phase, or hook spans when tracing is on. CI output lands in the same backend as application and infrastructure telemetry, so investigating a slow job stops requiring a tool switch.

  5. 6d ago

    More Buildkite workflows are available through APIs

    REST and GraphQL coverage expands across pipeline creation, organization administration, notification services, hosted agent resources, and artifacts, with pipeline creation now rejecting blank step configuration up front. Breadth rather than a new capability, but it is the groundwork that makes the headless-CI direction usable end to end.

  6. 7d ago

    Buildkite MCP Server can now wait for a build to finish

    The MCP server gains wait_for_build, which blocks up to 45 seconds for a build to reach a terminal state and returns elapsed time if it has not, replacing hand-rolled polling loops in agents. A small tool that meaningfully cuts the call volume and token cost of an agent supervising a build.