pipeline-doctorlisted

# Pipeline doctor CI failures are diagnosed badly by default because the log is long, the real error is near the top, and the loudest output is near the bottom. Work top-down and classify before fixing. ## 1 — Fetch the logs ```bash gh run list --branch <branch> --limit 5 gh run view <id> --log-failed # GitHub: only the failing steps az pipelines runs show --id <id> # Azure DevOps; logs via the REST API glab ci trace # GitLab ``` Where no CLI is available, read the log through the web UI. Reading the whole log unfiltered wastes the run — start from the failing step. Take **the first error**, not the last. Everything after the first failure is usually consequence: a build that failed produces test failures, missing artefacts and cleanup errors, none of which are the cause. ## 2 — Classify The class determines the fix, and misclassifying costs the most time. Establish it before changing anything: | Class | Signature | Response | |---|---|---| | **Real** | Reproduces locally on the same commit | Fix the code — `bug-hunt` or `green-gate`'s repair loop | | **Flake** | Same commit passes on re-run; timing, ordering or network-shaped | Hand to `flaky-triage`. Not a re-run. | | **Infrastructure** | Runner out of disk, registry timeout, network unreachable, image pull failure | Not yours to fix in code. Report it; retry once is legitimate here. | | **Config** | Missing secret, wrong runner image, cache key collision, permissions | Fix th