# Read CI results and logs Once [Buildkite is connected](https://mn.staging.git.cafe/docs/ci/buildkite.md), 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](https://mn.staging.git.cafe/docs/ci/actions.md) report checks the same way; their runs and logs are on the repository's **CI** tab ([follow runs and read logs](https://mn.staging.git.cafe/docs/ci/actions.md#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](https://mn.staging.git.cafe/docs/integrations/check-runs.md), 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 ` / `, 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](https://mn.staging.git.cafe/docs/repositories/repository-rulesets.md); a pull request cannot merge until they pass on the exact commit being merged. ```sh cafe pr status 42 ``` `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. ```sh cafe ci list --branch main # workflow runs and Buildkite builds cafe ci list --source buildkite --pr 42 # Buildkite builds at a pull request's head cafe ci watch ``` `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](https://mn.staging.git.cafe/docs/ci/actions.md#follow-runs-and-read-logs)). It polls less often while a run reports no progress and gives up after two hours (`--timeout `). ## 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](https://mn.staging.git.cafe/docs/ci/buildkite.md#share-job-logs). 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 ```sh cafe ci jobs cafe ci logs --output job.log cafe ci logs --tail 200 ``` `--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](https://mn.staging.git.cafe/docs/integrations/github-sync.md), 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: ```sh cafe pr status 42 cafe ci logs https://github.com/acme/project/runs/53845667812 # the last 200 lines cafe ci logs https://github.com/acme/project/runs/53845667812 -o job.log # the whole log ``` `--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.