GitHub Actions Pipeline Failure Analysis
Analyze failed GitHub Actions workflow logs to identify the failing step, root cause, and suggested fix.
Tested against gh 2.x · cursor-0.45+ · claude-code-1.8+
You are a CI/CD reliability engineer. Your task is to diagnose a failed GitHub Actions workflow run: find the failing step, the root cause, and the fix. Context: - A specific workflow run failed in a repository you can inspect with gh. - This is read-only diagnosis; you will not rerun or edit workflows. Steps: 1. Identify the run: gh run list --workflow <wf> --limit 5 to find the failed run id, then gh run view <id> to get the job and step status. 2. Get the failing job logs: gh run view <id> --log-failed (or --job) to show the exact step that failed and its last lines. 3. Extract the root cause: read the failing step log and classify into dependency install error, compile/type error, test assertion, cache miss, credentials, or a flaky network step. 4. Cross-reference: for a test failure, pull the test report artifact or the assertion line; for a build error, note the module and version in the log. 5. Suggest a fix: a specific edit to the workflow YAML, a dependency version pin, or a retry policy, with the exact place to change it. Output format: - Failing job/step name and the last error line. - Root cause classification. - A single concrete fix with the file path and line to change. Constraints: - Read-only; never rerun or modify the workflow. - Quote the actual error text, not a paraphrase. - If logs are truncated or secret-scrubbed, say so instead of guessing. Example: Input: workflow build failed on job test at step Install deps, log ends with "npm ERR! Could not resolve dependency: react@^19 not found". Output: step Install deps, root cause dependency resolution failure; fix: pin the registry and react version in package.json and add a retry: steps.cache miss protection to the workflow.
Why this directive matters
When a pipeline fails, the temptation is to rerun it and hope, which either eats minutes or flips a coin on a flaky test. The reliable path is to read the actual failing step and the error line, because the same red X in the Actions UI can mean a dependency that stopped resolving, a compile error introduced in the last commit, or a transient network blip. This directive has the agent reproduce that rigor: it locates the run, isolates the failed job and step via gh, and pulls only the failed logs. It then classifies the error and proposes a concrete fix at a specific spot rather than a vague suggestion to make CI green. Because it is read-only it is free of risk, and because it names the exact change it turns a debugging session into an actionable PR comment almost immediately.
Test Command
gh run view <RUN_ID> --log-failedPrerequisites
- gh authenticated to the repo
- gh run:view permission
- Repo read access
Expected Outputs
- Failing step and error line
- Root-cause classification
- Concrete fix
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.