AgentsCI/CDGitHub Actions Pipeline Failure Analysis

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+

DIRECTIVE / cicd-pipeline-failure-analysis
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-failed

Prerequisites

  • 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

THE NEXT STEP

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.