fix(check-ci-coderabbit): PR の CI 状態を statusCheckRollup から取得する - #343
Conversation
📝 WalkthroughWalkthroughCI 取得をブランチ単位の ChangesCI ロールアップ検出
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant run_check
participant GitHubCLI
participant parse_ci_rollup
run_check->>GitHubCLI: PR の statusCheckRollup を取得
GitHubCLI-->>parse_ci_rollup: rollup JSON を渡す
parse_ci_rollup-->>run_check: CI 状態を返す
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)(該当なし — レビュー未着のため指摘自体が存在しない) Applicable Findings (Medium 以下)(該当なし) Filtered (not applicable)(該当なし) 次のアクション
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/check-ci-coderabbit/src/parsers.rs (1)
53-67: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value判定ロジックの重複を統合する余地がある。
is_coderabbit_status_contextの判定式は、同じファイル内のparse_coderabbit_statusが使う filter closure と同一のロジックです。共通ヘルパーへ抽出すると、マッチ条件を変更する際に更新箇所を1つに集約できます。♻️ 提案する統合案
+fn contains_coderabbit(context: Option<&str>) -> bool { + context.map(|c| c.contains("CodeRabbit")).unwrap_or(false) +} + fn is_coderabbit_status_context(item: &GhRollupItem) -> bool { - item.context - .as_deref() - .map(|c| c.contains("CodeRabbit")) - .unwrap_or(false) + contains_coderabbit(item.context.as_deref()) }
parse_coderabbit_status側の filter も同じヘルパーを使うように置き換えられます。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/check-ci-coderabbit/src/parsers.rs` around lines 53 - 67, is_coderabbit_status_context と parse_coderabbit_status に重複している CodeRabbit context 判定を統合する。parse_coderabbit_status の filter closure を is_coderabbit_status_context の共通ヘルパー呼び出しに置き換え、既存の判定条件と結果を維持する。
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/check-ci-coderabbit/src/parsers.rs`:
- Around line 53-67: is_coderabbit_status_context と parse_coderabbit_status
に重複している CodeRabbit context 判定を統合する。parse_coderabbit_status の filter closure を
is_coderabbit_status_context の共通ヘルパー呼び出しに置き換え、既存の判定条件と結果を維持する。
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 754bfba0-5b1e-457d-bb6d-6d029c88b9c9
📒 Files selected for processing (4)
docs/adr/adr-064-monitor-success-positive-evidence.mdsrc/check-ci-coderabbit/src/main.rssrc/check-ci-coderabbit/src/models.rssrc/check-ci-coderabbit/src/parsers.rs
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)(該当なし) Applicable Findings (Medium 以下)
Filtered (not applicable)(該当なし) 次のアクション
|
…3) (#346) PR #342/#343/#344 の post-merge feedback 採用候補 14 件のうち、2026-08-02 の 方針決定 (文書系 10 件 = 1 docs バッチ PR、実装系 4 件 = A/B 系統別 PR) に従い 5 エントリとして登録: - 順位 359: 文書系 10 件の docs バッチ (dev-conventions 集中、Severity High 2 件含む) - 順位 360: cargo test コマンド等価性検証テスト (#342/#343 で連続指摘 = Frequency High) - 順位 361: JJ_VERSION の 2 ファイル一致検証テスト (順位 360 と同一 PR 可) - 順位 362: git subprocess ブランチ名依存引数の custom lint rule (#343 incident 由来) - 順位 363: check-ci-coderabbit の detached HEAD 回帰統合テスト (順位 362 と同一 PR 可)
Summary
fetch_ciをgh run list --branchからgh pr view <pr> --repo <repo> --json statusCheckRollupへ変更し、ブランチ名解決を経路から除去git branch --show-currentに依存していたget_current_branchを削除CheckRun/StatusContext) を正規化するparse_ci_rollupを追加。大文字の GraphQL 語彙を小文字化し、実行中 (conclusion: null) はstatusへフォールバックci.overallから除外。CR はdecide()の専用 gate (rate-limit / evidence backstop) で扱う契約を壊さないためsuccessではなくpending(ADR-064 の陽性証拠原則)Context
Why: 本リポジトリは jj colocated で git HEAD が detached のため
git branch --show-currentが常に空を返し、fetch_ci("")が早期 return して CI が恒久的にpending/runs: []になっていた。なぜ今まで表面化しなかったか: PR に status check を出す workflow が存在せず (
release-binaries.ymlは master push 限定、pr-monitor.ymlは意図的にpull_requestを使わない)、「CI 未設定」と「CI を観測できない」が同じ出力だった。ADR-065 の CI matrix (PR #342) が PR 単位の check を初めて生み、実際には failure だった Windows leg をpendingと報告し続けることで露見した。併せて閉じた 2 つ目の穴:
gh run list --branch X --limit 5はブランチ上の全 SHA の run を返すため、push 後に前 commit の結論を現在の結論として報告しうる (ADR-064 が排除した silent success と同型)。rollup は PR head SHA スコープなのでこの経路が構造的に閉じる。Scope decision: PR #342 (WP-16) とは別 PR にした。あちらは CI 基盤の新設、本 PR は監視コンポーネントの修正で変更単位が異なる。
Validation
overall: pending,runs: []overall: failure,runs: [rust (ubuntu-latest)=success, rust (windows-latest)=failure]review_state: successは専用経路で保持され、CR status が CI 判定に混ざらないことも確認cargo test -p check-ci-coderabbit: 112 passcargo clippy --all-targets --all-features -- -D warnings: cleanpnpm pushpre-push review: simplicity=needs_fix → fix 適用 → post_takt_regate で quality_gate 再実行 → 全グループ成功、security=approved--repo明示) は採用者側で独立に再検証した (上記 E2E + テスト + clippy)References
ghの cwd auto-detection が jj workspace で不安定 (--repo明示の根拠)Summary by CodeRabbit
バグ修正
ドキュメント