padosoft-ci-failure-triagelisted

# CI failure triage The failed-step extract tells you **where the run stopped**, not why. The cause is frequently in a step that passed — the database setup, the cache warm-up, the migration — or in a warning nobody reads. **The rule: never propose a fix for a CI failure from the summary. Collect everything, correlate, classify, then fix — naming the file and the line.** --- ## 1. Collect, before any hypothesis ```bash # the red run gh run list --workflow=<workflow>.yml --status=failure --limit 1 gh pr checks <PR> # everything it produced, into a gitignored directory mkdir -p ./_ci-debug/<RUN_ID> gh run download <RUN_ID> --dir ./_ci-debug/<RUN_ID>/ gh run view <RUN_ID> --log > ./_ci-debug/<RUN_ID>/full.log # mandatory gh run view <RUN_ID> --log-failed > ./_ci-debug/<RUN_ID>/failed.log # triage shortcut only ``` `--log-failed` is an extract. **The complete log is the requirement**, because the failing assertion is often a consequence of something three steps earlier that exited zero. When the artifacts are too large to pull whole, fetch by name or pattern rather than skipping them — and use a pattern, so a sharded matrix does not leave you with one shard out of six: ```bash gh run download <RUN_ID> --pattern "app-logs*" ``` ## 2. Read in this order 1. **The full run log** — including the steps that passed. 2. The failed-step extract, for fast orientation. 3. **The structured report**, if the runner emits one: the failure classification, silent errors, b