CI Job Failure Diagnosis

CI Job Failure Diagnosis

Scope: diagnose + propose. Never apply, commit, or push automatically.

When to use

User shares a GHA URL (actions/runs/<id>, actions/runs/<id>/job/<id>, or pull/<n>/checks?check_run_id=<id>) and asks why it failed.

• No URL → ask. Don't guess from recent context.
• Non-camunda/camunda repo → tell user this skill assumes monorepo conventions; some fixes won't apply.

Prerequisites

• gh auth status works against camunda/camunda.
• CWD is the repo root.
• incident.io MCP — tools are deferred behind ToolSearch; load them before deciding the server is unavailable. Only skip Step 4 if loading genuinely fails.

Hard rules — read first

1. NEVER increase a job/step timeout. Timeouts are contracts. Fix the slow work, the cache, the runner size, or (one-off pull_request only) rerun. Per ci.md §flaky tests: retry within the timeout.
2. NEVER propose workflow/cache/retry/sizing changes without reading and quoting ci.md. Silent or contradicts → drop. Use the prescribed composite actions (setup-maven-cache, setup-yarn-cache); cache writes only from main/stable*.

Procedure

1. Parse URL → run_id (required), job_id (optional), attempt (optional)

For check URLs, check_run_id is the job id. /attempts/<n> → attempt=<n>.

2. Pull run and job metadata

gh run view <run-id> --repo camunda/camunda [--attempt <n>] --json \
  status,conclusion,name,headBranch,headSha,event,workflowName,jobs,url,attempt

Default returns the latest attempt — a successful rerun masks the original failure. Always pass --attempt <n> if the URL had one; thread it through Step 7's --log-failed too.

• in_progress → tell user, stop.
• success → tell user, ask what they actually want.