ci-failures

Extract failure-identifying lines from failing GitHub Actions runs and GitLab pipelines.

Updated Aug 4, 2026

Search Tags:#debugging #github actions #gh cli #gitlab #ci #glab #failure logs

One-click install

npx skills add https://github.com/tschallacka/ai-skills --skill ci-failures-tschallacka

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: ci-failures
Source: https://github.com/tschallacka/ai-skills/tree/main/ci-failures
Command: npx skills add https://github.com/tschallacka/ai-skills --skill ci-failures-tschallacka

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires bash, rjq, gh, glab, and includes scripts (resource) components.

What problem does it solve? Reading a failing CI run by hand means listing jobs, fetching each log through the API, stripping ANSI escape codes and carriage returns, then searching for the lines that actually identify the failure. This Skill turns that six-step manual process into one command that prints only the failure-relevant lines per failing job. ## Core Features & Use Cases - Failure extraction, not full logs: Prints panics with following lines, test-suite `Failed:` summaries, `test result: FAILED`, GitHub `##[error]` annotations, and repository-specific `FAIL`/`portability:` findings per failing job. - Dual-forge support: Detects GitHub vs. GitLab from the git remote (or `CI_FAILURES_FORGE` override) and uses `gh api` or `glab api` against documented REST endpoints, naming the chosen forge on the first output line. - Flexible targeting: Resolves a run/pipeline from an id, a PR/MR number, `pr/N`, a branch name, or nothing (current branch), with a stated magnitude heuristic disambiguating bare numbers. - Use Case: A pull request's checks went red. Run the script with the PR number and immediately see which job failed and the exact panic or test failure line, instead of scrolling through thousands of log lines in the web UI. ## Quick Start Ask the agent to run scripts/ci-failures.sh with your PR number, branch, or run id to show what actually failed in the red CI run.

Frequently Asked Questions about ci-failures

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I find what failed in a GitHub Actions run from the command line?▼

Run scripts/ci-failures.sh with a run id, PR number, or branch name. It fetches each failing job's log via gh api, strips ANSI codes, and prints only the failure-identifying lines such as panics, Failed: summaries, and ##[error] annotations.

How do I read a failing GitLab pipeline job log with glab?▼

The script resolves the pipeline from an id, MR number, or branch, then calls glab api on the projects/:id/jobs/:id/trace endpoint for each failed job. It extracts failure lines and can write full de-escaped logs to a directory with --raw.

Does it support both GitHub and GitLab repositories?▼

Yes. It detects the forge from the git origin remote: github.com uses gh, gitlab.com uses glab, and self-hosted remotes fall back to whichever CLI is authenticated. CI_FAILURES_FORGE=gh or glab overrides the detection.

What happens when no log lines match the failure patterns?▼

The script says so explicitly instead of staying silent and points at the --raw DIR option, which writes each failing job's full de-escaped log to a directory for manual reading.

How does it distinguish a run id from a PR number?▼

By magnitude: a bare number with 9 or more digits is treated as a run/pipeline id, fewer digits as a PR/MR number. This is a stated heuristic, and the pr/N prefix disambiguates when the guess is wrong.

When should I not use this CI failure extraction script?▼

Do not use it to trigger new CI runs or on repositories with no CI at all. Also note the GitLab path is tested only against a stubbed glab binary, so its first live run against a real GitLab project is still an unverified step.