> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/connectors/buildkite.md).

# Buildkite

## Overview

The Buildkite connector gives Nullify eyes on your CI. When Nullify opens an autofix pull request, your Buildkite pipeline runs against it like any other change — and if that build fails, Nullify reads the failure and fixes its own work before a human ever has to look. Once connected, Nullify can:

* **See your Buildkite builds** on the pull requests it opens, including pass/fail status.
* **Read the logs of a failed build** straight from the Buildkite API to understand *why* CI broke.
* **Iterate on the fix automatically**, feeding the real CI failure back to the autofix agent until the build is green.

The result is an autofix loop that's accountable to your actual pipeline — linting, tests, type checks, build steps and all — not just to Nullify's own checks. Teams that run Buildkite for CI alongside GitHub for source control get fixes that are already CI-clean by the time they land in review.

## How it works

Nullify never sits in the critical path of your pipeline and never changes how your builds run. It watches, reads, and iterates:

1. **Nullify pushes an autofix commit** to a pull request.
2. **Buildkite runs your pipeline** against that commit, exactly as it would for any developer push. (If your org gates *who* can trigger builds, Nullify's Buildkite user needs a seat on an allowed team first — see [Configuration → Step 5](/connectors/buildkite/configuration.md#build-creator-access).)
3. **Buildkite reports the result to GitHub** as a commit status (this is Buildkite's standard GitHub integration).
4. **Nullify detects the status** through its GitHub App — including when the build fails.
5. **Nullify fetches the failed job logs** from the Buildkite API using your connected token.
6. **The autofix agent iterates**, using the real failure output as context, and pushes a new commit — which kicks off the loop again until CI is green.

```
Autofix commit ─▶ Buildkite pipeline runs ─▶ Build fails
                                                  │
                          GitHub commit status ◀──┘
                                   │
                          Nullify detects failure
                                   │
                       Fetches Buildkite job logs ─▶ Agent iterates ─▶ new commit ↺
```

The integration is **read-only on your CI**: Nullify reads build status and logs. It does not trigger, cancel, or modify your pipelines, and it does not write anything back to Buildkite.

## Prerequisites

Before you start, make sure you have:

* A **Buildkite organization** with at least one pipeline that runs on your pull requests.
* The [**Buildkite GitHub App**](https://buildkite.com/docs/integrations/github#connect-your-buildkite-account-to-github) installed on your GitHub organization, with **commit statuses** enabled (this is how build results reach GitHub — and therefore Nullify).
* **GitHub already connected to Nullify.** Buildkite layers on top of the GitHub connection; it is not a standalone source-control integration.
* A **Buildkite API access token** with just two scopes — `read_builds` and `read_build_logs`.
* **If your organization restricts who can trigger builds** (build-creator team gating): the ability to invite Nullify's Buildkite user to your org and add it to an allowed team — see [Configuration → Step 5](/connectors/buildkite/configuration.md#build-creator-access). Without this, Nullify's autofix commits never run a build in a gated org, so there's nothing for Nullify to read.

{% hint style="info" %}
**Use a dedicated service account for the API token, not a personal one.** Create a Buildkite user that exists only for Nullify (for example, `nullify-ci@yourcompany.com`), give it access to the organization, and mint the token from that account. This keeps the integration alive when people change teams or leave, scopes Nullify's access to exactly what that user can see, and makes the token easy to audit and rotate.

This token account is **separate** from Nullify's own Buildkite user (`integrations-bot@nullify.ai`) in [Configuration → Step 5](/connectors/buildkite/configuration.md#build-creator-access) — that user exists so Nullify's *commits* can trigger your builds in gated orgs, and is unrelated to the read token.
{% endhint %}

## Next steps

Follow the [**Configuration**](/connectors/buildkite/configuration.md) guide to create the token and connect your Buildkite organization.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.nullify.ai/connectors/buildkite.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.