CI failure explainer
By Toolspoke
Give it a red build and it reads the failing run down to the step and line that broke, and says whose problem it is.
Needs a Toolspoke account. You choose which project it installs into.
GitHub
Its last step
Answer in four lines
- GitHub
- Required integrations
- Runs when you ask
- No schedule of its own
- Answer in four lines
- What its last step does
- Nothing destructive
- 0 of 26 actions in its tools
On this page
The short version
- What it is
- Give it a red build and it reads the failing run down to the step and line that broke, and says whose problem it is.
- Works with
- GitHub
- How often
- When you ask it to.
- What it never does
- Re-run, cancel or dispatch a workflow.
- What you need
- A Toolspoke account, with GitHub connected.
How it works
What each run does, from the "Steps" part of its own instructions.
- Step 1:
Find the run
From a pull request, get its head commit and list the workflow runs for it. From a branch, take the latest run on that branch. Use the most recent failed attempt, not an older one.
- Step 2:
Find the first failing job and the first failing step inside it
Later failures are often the first one repeated.
- Step 3:
Read to the real line
A step that says "exit code 1" is a summary. Go to the test name, the assertion, the compiler error or the lint rule, and quote it exactly.
- Step 4:
Decide whose it is
This change: the failing file or test is touched by the pull request's diff. Name the file. The branch: the same job fails on the base branch's latest run. The change is innocent. The pipeline: a timeout, a runner that ran out of disk, a network fetch that...
- Step 5:
Answer in four lines what failed, the exact error, whose it is, and the smallest next step.
What you get
How the agent's own instructions describe what it hands back. Install it to see a real result.
Answer in four lines what failed, the exact error, whose it is, and the smallest next step.
Integrations & requirements
CI failure explainer needs GitHub to work. You sign in to each one yourself.
GitHub
RequiredManage repositories, issues, pull requests, and Actions.
Authentication: Personal access token
Skills it follows
| Tool | Actions it offers |
|---|---|
| GitHub | 26 in all: 16 read, 10 write, 0 destructive. Nothing that deletes or permanently changes anything. |
A project can switch any action off, and every call is logged. The counts are what each tool offers; which of them the agent uses is up to its instructions.
What it will never do
- Re-run, cancel or dispatch a workflow.
- Open a pull request, push a commit, or comment on the pull request unless the person asks you to post your answer there.
If something goes wrong
If the logs have expired or the run cannot be read, say so and say what you could see, such as the job name and the step that failed. Do not guess at the cause from the job name alone.
These are written into CI failure explainer's instructions. They guide the agent, but they are not a permission. What it is allowed to touch is set by the access you grant.
When it runs
CI failure explainer has no schedule. It runs when you ask it to.
Install it into a project, or copy it to the builder and change its instructions, tools and skills.
Use CI failure explainer
Pick a project and connect the tools it needs.