name: ci-status-inspector description: 失敗した PR check や commit pipeline の CI provider を特定し、GitHub Actions / Woodpecker / GitLab CI のどれが失敗しているかを正確に切り分ける。外部 status URL、pipeline URL、commit SHA から exact target を調べたいときに使う。

ci-status-inspector

$ci-status-inspector は、失敗した check の provider を判定し、repo 全体の最新状況ではなく「その check が指している実体」を優先して調査する。

provider 判定

repo 構成よりも、check 自体のメタデータを優先する。

1. まず failing target を確認する。
   • GitHub PR: gh pr view <pr> --json statusCheckRollup,headRefOid,url
   • commit status: gh api repos/<owner>/<repo>/commits/<sha>/status
2. 次に provider を分類する。
   • GitHub Actions: detailsUrl が github.com/.../actions/runs/...
   • Woodpecker: context が ci/woodpecker/ で始まる、または URL が /repos/<repo-id>/pipeline/<n>/... に一致する
   • GitLab CI: URL が GitLab pipelines/jobs を指す、またはタスクが明示的に GitLab CI を対象としている
3. repo ファイルは fallback signal としてだけ使う。
   • .woodpecker.yml
   • .github/workflows/
   • .gitlab-ci.yml
4. 複数 provider が混在する場合は、failing check の detailsUrl を最優先する。まだ曖昧なら、曖昧さと根拠を明示して止める。

exact target の優先順位

次の順で selector を選ぶ。

1. pipeline URL
2. pipeline ID / number
3. commit SHA
4. latest pipeline

障害調査で latest に頼るのは、他に selector がない場合だけにする。

GitHub Actions の流れ

失敗 check が GitHub Actions なら、この流れを使う。

• GitHub PR check の失敗調査が主目的なら、$gh-fix-ci が使える場合はそちらを優先する
• それ以外は gh pr checks <pr> と gh run view <run-id> --log を使う
• failing job 名、failing step、最小の再現ヒントだけを要約する
• 外部 check を GitHub 上に見えているという理由だけで GitHub Actions 扱いしない

Woodpecker の流れ

失敗 check が Woodpecker を指している場合は、bundled script を使う。

前提:

• WOODPECKER_TOKEN
• 任意: WOODPECKER_HOST（既定 https://mashirou.stream）

bundled script:

• scripts/get-woodpecker-pipeline-status.sh

推奨コマンド:

# 最優先: GitHub status の target_url をそのまま渡す
scripts/get-woodpecker-pipeline-status.sh --pipeline-url <target_url>

# repo id / pipeline number が分かっている場合
scripts/get-woodpecker-pipeline-status.sh --repo-id <repo_id> --pipeline-id <pipeline_number>

# commit しか分からない場合
scripts/get-woodpecker-pipeline-status.sh --repo <owner/repo> --commit <sha>

解釈ルール:

• workflow_failures を最優先で読み、具体的な failed workflow / plugin / command step を特定する
• errors は config validation や lint 段階の reject を示すことが多い
• --strict は selected pipeline が success でない限り exit code 3 を返すので、自動ガードに使える
• PR 調査では、同じ commit に複数 pipeline がある場合 push より pull_request を優先する

GitLab CI の流れ

失敗 URL またはタスクが明確に GitLab CI を指している場合は、この流れを使う。

• 既存の GitLab 向けツール（glab や内部 script）があればそれを優先する
• API が使えるなら、latest pipeline ではなく exact pipeline/job URL を直接見る
• token や tooling が無ければ推測せず、足りない前提を明示して止める

この skill は現在 Woodpecker helper script を同梱している。GitLab については workflow guidance を定義し、bundled implementation はまだ持たない。

出力形式

返答は provider を意識した短い要約に揃える。

• Provider
• 使った exact target（pipeline-url / pipeline-id / commit / latest）
• Pipeline status
• Failing workflow / job / plugin / step
• Key error text
• 今回の diff 起因か、既存 CI / infrastructure 起因かの見立て

resources

scripts/get-woodpecker-pipeline-status.sh

Woodpecker API を exact selector で問い合わせる helper script。

次の場面で使う。

• GitHub status が Woodpecker URL を返している
• Woodpecker の PR pipeline を正確に調べたい
• latest pipeline に依存せず commit から exact pipeline を引きたい