Investigate GitLab CI pipeline failures and extract diagnostic information. Use when checking pipeline status, debugging failed jobs, or monitoring CI after a push. Identifies failing jobs, extracts relevant error output, and returns a concise summary.
Analyzes GitLab CI pipeline failures by identifying failing jobs and extracting relevant error logs.
npx claudepluginhub bendrucker/claudeThis skill is limited to using the following tools:
references/log-parsing.mdInvestigate GitLab CI pipeline failures and extract diagnostic information. Extract only: find the failures and present them concisely. Do not analyze root causes or suggest fixes.
$ARGUMENTS
If no pipeline ID or MR is specified, use the current branch.
!glab ci status 2>/dev/null || echo "no pipeline"
From the pipeline status above, identify the relevant pipeline. If still running, use glab ci status --wait to wait for completion.
glab ci get --output json | jq '[.jobs[] | select(.status == "failed") | {name, id, stage, status}]'
If glab ci get is unavailable, use glab ci list to find the pipeline ID and glab api projects/:id/pipelines/<pipeline-id>/jobs for job details.
For each failing job, fetch its log:
glab ci trace <job-id>
Parse the log output for failure-relevant sections. See references/log-parsing.md for CI-specific log structure.
When multiple jobs fail, fetch logs for each job in separate parallel Bash calls.
For each failed job, report:
Keep the total output concise. The parent conversation will use this to investigate.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.