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.