Read CI results and logs#

Once Buildkite is connected, GitCafe shows build results on the repository's CI tab and as checks on pull requests and commits. Workflows that GitCafe runs itself with Actions report checks the same way; their runs and logs are on the repository's CI tab (follow runs and read logs).

See checks on a pull request#

The checks panel on a pull request's Conversation tab lists every check on its latest commit: Buildkite and GitCafe checks (including one per Actions job and one per Actions workflow), checks apps and scripts report through the API, commit statuses and checks imported from GitHub. A GitHub check re-run on the same commit shows only its newest attempt, as GitHub does. A commit's page shows the same panel. The badge summarizes them all, and a check's name opens its log in GitCafe (a commit status's name links to its own target). Checks are grouped into Failing, In progress, Successful and Skipped sections; the first two stay open, and the panel's footer shows or hides the other two. An app's suite of checks stays together, in the section of its worst check. The header counts every check. An Actions job's check is named <workflow name> / <job name>, with each matrix combination under its own name, such as CI / test (22). GitHub names the same check test (22), so update required check names you carry over from GitHub.

Required checks are set with rulesets; a pull request cannot merge until they pass on the exact commit being merged.

cafe pr status lists every check on the pull request's head commit, Actions jobs and Buildkite builds alike, with whether it is required and, when it has one, a link to its run. cafe ci status --pr 42 shows the CI runs at that commit: workflow runs and Buildkite builds.

Browse runs#

Open the repository's CI tab to list runs. Filter by status and page back through older runs; active runs refresh while the page is open. Select a run to see its jobs and logs.

cafe ci lists GitCafe Actions workflow runs and Buildkite builds together, newest first, like the CI tab; --source actions or --source buildkite shows one. --branch lists the runs on that branch, not only at its tip. cafe ci watch waits until the run finishes and exits nonzero unless it succeeded (follow runs and read logs). It polls less often while a run reports no progress and gives up after two hours (--timeout <minutes>).

Read a job log#

Open a run, or select a check's name on a pull request. Failed jobs are listed first, and the first failed job's log opens automatically. The job is part of the address, so you can share a link to it.

The viewer shows the log as it appeared in the terminal, with colours and progress lines:

• It starts with the last 256 KB. Load 256 KB more loads earlier output; Load the whole log loads all of it.
• The failures button steps through lines that report a failure: failed tests, compiler errors, panics and non-zero exit codes.
• Search finds text in the loaded output (Enter for next, Shift+Enter for previous). Sections jumps to a Buildkite section header.
• Download saves the whole log; Copy copies the loaded part.
• While a job runs, new output appears every few seconds. Latest output jumps back to the end.

Logs are available only when the repository shares them. A job that has not started has no log yet; a step Buildkite never ran on this build (for example one its branch filter excludes) is listed as Skipped.

Download logs from the CLI#

--full prints the whole log, --tail N the last N lines, and, for a Buildkite job, --bytes FIRST-LAST one byte range.

Read a GitHub check's log#

On a repository synced with GitHub, checks imported from GitHub keep their results in GitCafe but not their logs. GitCafe reads a log from GitHub when you ask for it, with the repository's GitHub App installation, so it takes a little longer than a GitCafe log.

GitHub keeps job logs only for GitHub Actions. A check from another app (codecov, a linter, another CI) has no log to read: open it on GitHub, where its app's report is. cafe ci logs fails for one with an error that gives its GitHub link. A job that has not finished and a log GitHub no longer keeps are errors too, never an empty log. Reading logs needs the GitHub App's Actions: read permission, and logs over 64 MiB are refused.

On a pull request's Conversation tab, select a GitHub Actions check's name to open its log in the same viewer as a GitCafe job, with search, failure stepping, Copy and Download; GitHub opens the check there. Another app's check links to its own page, as do checks imported before GitCafe recorded which app made them. GitHub serves a job's log only once the job finishes, so a running job has none yet. In the CLI, cafe pr status prints each GitHub check's link, which cafe ci logs takes in place of a run id:

--tail N prints the last N lines and --full the whole log.

See GitHub Actions runs synced from GitHub#

The repository's CI tab lists the GitHub Actions runs of its GitHub mirror next to GitCafe Actions runs and Buildkite builds, each marked Synced from GitHub; choose GitHub (synced) as the source to see only them. GitCafe groups the synced jobs of one GitHub workflow run (one check suite) into a run and keeps the latest attempt of each job, so a list row is named by its jobs, failing ones first. GitCafe keeps no ref for these runs, so a branch filter leaves them out. Jobs synced before GitCafe recorded their check suite are not grouped into runs; they still show on the pull request.

Open a run to see it laid out like a GitCafe Actions run: its jobs, then the chosen job's steps and log. The workflow's name, run number, event and branch, the steps and the log are read from GitHub when you open the run, so they take a little longer; without the GitHub App's Actions: read permission the run is named by its jobs and shows no steps or logs. GitHub opens the run there.