CI/CD Status Queries

Query CI/CD pipelines and check merge readiness across GitHub Actions and GitLab CI. All recipes use minimal field sets for token efficiency. Covers pipeline status, failing jobs, run logs, workflow management, and merge readiness assessment.

Verified against gh v2.103.2 (2026-10-27): every gh subcommand and flag used here, against its --help on v2.102.0 (2026-09-30), then the pkg/cmd sources of v2.102.0 and v2.103.2 diffed (2026-10-27), since --help is generated from them: no flag of a subcommand used here changed. glab: not verified -- no pinned version yet; check glab <cmd> --help before relying on a glab flag. If gh --version is newer, read the release notes since v2.103.2 before relying on flag details.

When to Use

• Checking CI status -- "are checks passing?", "what's failing?", pipeline status
• Watching CI runs -- wait for completion, fail-fast on errors
• Debugging failures -- view logs for failing jobs, identify flaky tests
• Assessing merge readiness -- all checks green, reviews approved, no conflicts
• Listing workflow runs -- recent pipelines, specific workflow history
• Configuring CI allowlists -- auto-approval patterns for read-only CI commands

Critical Rules

1. Use gh pr checks (not gh run) for current-branch CI status. The pr checks subcommand maps directly to the PR's required status checks.
2. Use glab ci status for current-branch CI in GitLab. It shows the pipeline for the current branch without needing a pipeline ID.
3. Always use --json with gh to filter output fields. Full JSON output wastes tokens. gh pr checks accepts exactly bucket, completedAt, description, event, link, name, startedAt, state, workflow -- there is no conclusion field here (that one belongs to gh run and to statusCheckRollup), and an unknown field aborts the command with Unknown JSON field.
4. A check that did not fail is not always a completed job. App and bot checks report non-failing states for outcomes that did no work: CodeRabbit reports Review rate limited as a neutral check run (or, on its legacy commit status, a successful one) when it never reviewed the code. The outcome lives in the check run's summary or the status description; gh pr checks returns only the latter (when asked), and gh pr view --json statusCheckRollup drops both. See Review-Bot Checks below before calling a PR reviewed or merge-ready.
5. Use commands exactly as shown in this skill. The commands below are designed to match auto-approval allowlist patterns. Improvising flags may trigger permission prompts.

Provider Detection

git remote get-url origin

If ambiguous or both present, ask the user.

The glab recipes follow GitLab's documentation and are not exercised against a live instance -- the GitHub ones are. Confirm flags with glab <command> --help before depending on one unattended.

CI Status (Current Branch)

GitHub:

gh pr checks --json name,state,bucket,description

state is GitHub's raw verdict (check runs and legacy status contexts use different vocabularies -- SUCCESS, FAILURE, PENDING, SKIPPED, ...); bucket collapses it to exactly pass, fail, pending, skipping, or cancel. description carries the app's own summary line -- always request it: it is the only field that separates a check that did its job from one that merely reported (Critical Rule 4). Branch on the JSON, not on the exit status: gh pr checks exits 8 while checks are pending and non-zero when any fails or none are reported.

GitLab:

glab ci status          # current branch, one line per job
glab ci get             # full detail for the branch's pipeline

Review-Bot Checks (GitHub)

Review bots publish their outcome as a check that never fails. CodeRabbit writes a CodeRabbit check run by default (its review progress reports, reviews.review_progress), or the legacy commit status where reviews.commit_status keeps it. In the checks list it sits among the CI jobs, and a round that reviewed nothing still reads as "nothing failed".

# Check run (default): the verdict is the first line of output.summary, "Result: <outcome> - <verdict>"
# (gh api: not in this skill's allowlist, so it needs manual approval; the git-pr allowlist covers it)
gh api repos/{owner}/{repo}/commits/"$(gh pr view --json headRefOid --jq .headRefOid)"/check-runs --paginate --slurp | jq '[.[].check_runs[] | select(.app.slug=="coderabbitai")] | max_by(.completed_at // .started_at) | if . == null then empty else {status, conclusion, verdict: ((.output.summary // "") | split("\n")[0])} end'

# Legacy commit status: the verdict is the description, which gh pr checks returns when asked
gh pr checks --json name,state,bucket,description --jq '.[] | select(.name|ascii_downcase|startswith("coderabbit"))'

On the legacy status, across 25 PRs of one account, 15 of 62 rounds came back Review rate limited -- a green check next to the CI jobs meaning nothing was reviewed, roughly a quarter of the time. The check run at least buckets those as skipping, but gh pr checks shows no description for a check run and lumps a refused review with a skipped one: only the summary line says which.

gh pr view --json statusCheckRollup drops the verdict on both surfaces (a StatusContext has no description, a CheckRun only its conclusion), so avoid it for bot checks. Handling the rate-limited case (windows, re-triggers, the review loop, and bot_check, which reads both surfaces) is the git-pr skill's references/bot-review-loop.md.

Watch Until Complete

GitHub:

gh pr checks --watch --fail-fast

GitLab:

glab ci status --live

Recent Pipeline/Workflow Runs

GitHub:

gh run list --json databaseId,displayTitle,status,conclusion,headBranch,event --limit 10

GitLab:

glab ci list

Specific Run Details

GitHub:

gh run view {run_id} --json jobs,status,conclusion,displayTitle

GitLab:

glab ci view {pipeline_id}

Run Logs

GitHub:

gh run view {run_id} --log-failed

GitLab:

glab ci trace {job_id}

Merge Readiness (Current Branch)

GitHub:

gh pr view --json mergeable,reviewDecision,statusCheckRollup,isDraft,mergeStateStatus

Fields:

• mergeable -- MERGEABLE, CONFLICTING, or UNKNOWN
• reviewDecision -- APPROVED, CHANGES_REQUESTED, REVIEW_REQUIRED, or empty
• isDraft -- boolean
• mergeStateStatus -- CLEAN, BLOCKED, BEHIND, DIRTY, UNSTABLE

statusCheckRollup answers "did the checks pass", never "did each check do its job" -- it carries no description, so a bot check that reported a rate limit looks identical to one that reported a completed review. Pair it with the gh pr checks --json ...,description call above whenever a review bot gates the merge.

GitLab:

glab mr view -F json | jq '{merge_status:.merge_status,conflicts:.has_conflicts,blocking:.blocking_discussions_resolved,draft:.draft}'

Variables and Secrets

GitHub:

gh variable list
gh secret list

GitLab:

glab variable list

CI Queries Reference

Reference: See references/ci-queries.md for advanced patterns: failing check extraction, required checks, workflow listing, cache management, rulesets.

Allowlist

Reference: See references/allowlist.md for tiered Bash(command:*) patterns covering all read-only CI operations -- safe to auto-approve in Claude Code settings.json or OpenCode config.