Read CI logs
Open the failing part of a CI log without leaving Limn, and re-run failed jobs.
On this page
A pull request’s checks are listed on its Overview tab, in the Status row. For a check that runs on GitHub Actions, you can open its job log right there, read the end of it where the failure usually is, and re-run the failed jobs. Limn also marks checks that look flaky, so you know when a red build is probably not your code.
#Open a log
FAILED tests/test_refunds.py::test_partial_refund_email ConnectionResetError: [Errno 104] Connection reset by peer 1 failed, 212 passed in 41.2s
- Open the pull request and stay on the Overview tab.
- In the Status row, select a check’s row to show its job log. The log opens at its last lines.
- Scroll up to load earlier parts of the log.
- Select the row again to hide the log.
Logs open for passing checks too, if you want to see what a green check actually ran. A check that does not run on GitHub Actions has no log Limn can read, so it is listed with a link to where it runs.
#Re-run jobs
- Re-run failed jobs re-runs only the failed jobs of the failing workflow runs.
- Re-run all jobs re-runs the whole workflow runs from the start.
After you press, Limn says “Re-run requested — CI updates on the next sync.” The re-run goes out under your GitHub account, so you need push access to the repository.
#Flaky checks
A failing check gets a Flaky chip when either of these is true:
- Passed and failed on this commit: it passed earlier on the same commit and fails now.
- The CI review says: network or infrastructure: the CI review of this commit found the failure was a network or infrastructure problem.
On the Pending board, a card whose failing checks are all flaky offers Re-run failed jobs directly.
Ask AI what went wrong
While AI is on, the CI check section of the AI Review tab reads the failing logs and explains the cause; AI Fix can then work on it. See CI review.
#Why it helps
Most of a red build’s story is in the last lines of one log. Opening that log beside the pull request, and knowing whether it is flaky, saves a trip through GitHub Actions for every failure. For what blocks a merge, see Can it land?.