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; Runs 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 panel lists every check: GitCafe and Buildkite checks by name, then commit statuses, then GitHub checks; the badge summarizes all of them. 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 run page lists its jobs with failed ones first and opens the first failed job that has a log. The job is part of the page address (?job=<job-id>), so the link opens the same log.

The log viewer starts with the last 256 KB of output:

• Load 256 KB more at the top of the log loads earlier output; Load the whole log keeps loading until the log starts. The toolbar shows how much of the log is loaded.
• The log is shown in a terminal (Ghostty), as it appeared on the agent: colours, progress lines that rewrite themselves and cursor movement. If the terminal cannot load, the viewer shows plain text.
• The failures button counts rows that report a failure (failed tests and targets, compiler errors, panics, non-zero exit statuses) and steps through them. Search finds text in the loaded output; press Enter for the next match and Shift+Enter for the previous one. Sections lists Buildkite's section headers (~~~, ---, +++) and jumps to one.
• Download saves the complete log from …/log/raw, however much is loaded. Copy copies the loaded output as plain text and says Copy loaded while part of the log is not loaded.
• While a job runs, new output is added every few seconds and the view stays at the end unless you scroll up; Latest output returns there.

Access denials and Buildkite errors appear in the viewer.

Whole logs from the CLI and API#

The whole log is available to everyone who can view the excerpt. With the CLI, cafe ci logs <run-id> --job <job-id> --output job.log downloads it, --full streams it to stdout, --tail N prints the last N lines and --bytes writes one byte range; cafe ci jobs <run-id> lists job IDs.

Through the API, the job log is available as a JSON excerpt of any byte range (at most 256 KiB, ending on whole UTF-8 characters, so excerpts page backwards without gaps) and as a raw stream of the whole log that honours one Range header. The API reference documents both.