# Buildkite results and settings

Connect Buildkite to see build results on repository CI pages and pull requests.
Builds run in Buildkite; these settings do not start or schedule builds.

## Connect Buildkite

1. Open `/settings/integrations/buildkite` for personal repositories, or
   `/orgs/<owner>/settings/integrations` for an organization you administer.
2. Enter a display name and your Buildkite organization slug. Use the Token from
   the Buildkite webhook notification service as the webhook secret.
3. Add the displayed receiver URL to that notification service and select the
   `X-Buildkite-Signature` header.
4. Open the repository's **Settings → CI integrations**
   (`/<owner>/<repo>/settings/ci`). Choose an enabled integration, enter the
   pipeline slug and a check context, then save.

Stored webhook secrets are never displayed again. The secret field clears after
submission, including failed requests; re-enter it if you need to retry. When you
rotate the token in Buildkite, update the GitCafe secret to match.

Existing integrations can be edited, disabled, enabled or deleted with
confirmation. Repository pipeline connections can be disabled or deleted. If
another administrator changes the same configuration first, reload and review
those changes before retrying your save.

## Read build results

Open the repository **CI** tab (`/<owner>/<repo>/ci`). Filter runs by status,
page through older results, or refresh. Select a run to see its jobs and logs;
**Back to CI** returns to the list. Active runs refresh while the page is open.
Branch and commit links identify the code each run tested.

Pull request checks include Buildkite, GitCafe and imported GitHub results, with
provider links where available. Distinct runs can share a name. The checks badge
includes results beyond a limited visible list, so a failure may not appear among
the first rows. A limited list is labeled. If checks cannot be read, resolve the
error or refresh rather than assuming they passed.

## Publish results to GitHub

GitHub publication is an explicit choice for each pipeline connection. It requires
a linked GitHub repository and GitHub App Checks read/write permission for it.
Enable or disable publication in the repository's CI integration settings.

Publication status is separate from the build outcome. A run can be
**Successful** while **GitHub publication blocked** means its result has not been
published there. Check the connection and GitHub permissions when publication is
blocked. Pull request checks refresh while the page is open and when new commits
are pushed.

## Share and read logs

To make Buildkite jobs and logs available in GitCafe, save a Buildkite token with
`read_builds` and `read_build_logs` permission in the integration's separate log
access form. Saving or removing it does not require re-entering the webhook secret.

Log sharing is off by default. Enabling **Repository readers can view Buildkite
logs** shares them with everyone who can read the repository, including anonymous
visitors when the repository is public.

Use a check's **View jobs and logs** link, or select a run from the CI page.
The viewer retrieves log excerpts (64 KiB by default), labels omitted output, and
refreshes active jobs. You can pause following, copy, download, or view plain text.
A completed job can still have a truncated log excerpt. Access denials and
Buildkite errors appear in the viewer.