land-renovate は何をしますか？
現在のリポジトリ内のオープンなRenovate PRのキューを処理し、安全なものをランドします。 列挙、分類、承認 + リベースマージをPR番号の昇順で行い、残りのPRにはリベースチェックボックス、 実際の障害やHOLDケースでは適切に停止します。
このスキルは gh を介して既存のリモートPR上でのみ動作します。
/create-commit、/create-pr、/wrap は呼び出さず、ローカルコミットを作成しません。
引数
| 引数 | デフォルト | 説明 |
|---|---|---|
limit=N | 30 | 処理するPR数の上限を設定します。 |
<pr-number>... | すべてのRenovate作成オープンPR | スペース区切りのPR番号。指定されたPRのみを処理します。 |
デフォルト: 現在のリポジトリ（gh repo view --json nameWithOwner から取得）、
Renovate作成のオープンPR、PR番号の昇順、ラベルフィルターなし。
ワークフロー
1. リポジトリを特定する
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
2. Renovate PRを列挙する
Renovateが作成したオープンPRを、古いもの（番号が小さいもの）から順にリストします:
gh pr list -R "$REPO" --author "app/renovate" --state open --limit 30 \
--json number,title,mergeable,mergeStateStatus,statusCheckRollup
number で昇順にソートし、その順序で処理します。引数で特定のPR番号が渡された場合は、そのセットに制限します。
注意:
gh pr listは、GitHubがマージ可能性を遅延評価するため、mergeable: UNKNOWNを返すことがよくあります。単一PRに対してgh pr view <n> --json mergeableを実行すると、計算が強制されます。PRのmergeableがUNKNOWNの場合は、分類前にgh pr viewで再読み込みしてください。
3. 各PRを分類する
各PRを statusCheckRollup + mergeable + mergeStateStatus を使用してバケットに分類します:
| バケット | シグナル | アクション |
|---|---|---|
| GREEN | ロールアップに FAILURE/CANCELLED/TIMED_OUT なし、保留中なし、mergeable=MERGEABLE | 承認 + リベースマージ (ステップ4) |
| CONFLICTING | mergeable=CONFLICTING または mergeStateStatus=DIRTY | リベースチェックボックスをオン (ステップ5)、監視 |
| REAL_FAILURE | ロールアップに自動修正不可能な FAILURE を含む | スキップ、人間のトリアージに委ねる |
| HOLD | ファイル間の調整が必要（手動チェックリスト — 下記参照） | 人間向けに表示、先に進まない |
ロールアップ内のチェックは、CheckRun の status != COMPLETED または StatusContext の state が PENDING/EXPECTED の場合に保留中と見なされます。CheckRun.conclusion が FAILURE/CANCELLED/TIMED_OUT/ACTION_REQUIRED/STARTUP_FAILURE、または StatusContext.state が FAILURE/ERROR の場合は失敗です。
HOLD チェックリスト（手動 — ハードコードされていません）
HOLD検出はエージェントが行う判断であり、自動ルールではありません。単独でランドすると別のファイルに影響を及ぼす場合にPRをHOLD候補として扱います。例:
- terraform-version ピンの不一致 — Terraformプロバイダー/CLIのバンプで、他の場所（例:
.terraform-version、CIワークフロー、required_version制約）のピンも更新が必要な場合。 - スキーマバンプによるコード編集が必要 — 新しいメジャーバージョンでスキーマ/型が変更され、手書きコードがそれに依存している場合。ポストアップグレードフックではコード編集を生成できない。
- アップグレードの変更ログで、ポストアップグレードジョブが実行しない調整編集が必要な場合。
PRがHOLDのように見える場合は、それを表示してユーザーに問い合わせてください — 自動マージせず、リベースチェックボックスもオンにしないでください。残りのキューは引き続き処理します。
4. 承認 + マージ (GREEN)
gh pr review "$PR" -R "$REPO" --approve \
--body "LGTM — Renovate一括ランドの一環として自動承認されました。"
gh pr merge "$PR" -R "$REPO" --rebase --delete-branch
5. リベースチェックボックスをオンにする (CONFLICTING)
Renovateのリベースチェックボックスを反転させてブランチをリベースし、その後監視します:
body=$(gh pr view "$PR" -R "$REPO" --json body -q .body)
new=$(printf '%s' "$body" | sed 's|^\( *\)\- \[ \] <!-- rebase-check -->|\1- [x] <!-- rebase-check -->|')
printf '%s' "$new" | gh pr edit "$PR" -R "$REPO" --body-file - >/dev/null
チェックボックスをオンにする前に、現在のヘッドSHAをベースラインとしてキャプチャし、 その後モニター（ステップ6）を実行して、開始時の状態からのリベースを区別できるようにします:
BASELINE=$(gh pr view "$PR" -R "$REPO" --json headRefOid -q .headRefOid)
REAL_FAILURE に対してリベースチェックボックスをオンにしないでください — Renovateのサイクルを無駄にし、本当の問題を隠してしまいます。
6. 安定するまで監視する
バンドルされている scripts/monitor-renovate-pr.sh は、単一のPRをそのチェックが安定するまでポーリングし、エージェントがモニターツールを介して消費する判定を出力します。
scripts/monitor-renovate-pr.sh <pr-number> <repo> <baseline-head-sha-short>
- 45秒ごと（
POLL_INTERVALで上書き可能）にgh pr view --json headRefOid,mergeable,mergeStateStatus,statusCheckRollupをポーリングし、シグネチャ${head:0:9}|<mergeable>:<state>|ok=N pend=M fail=Kが変更された場合にのみ行を出力します。 - ヘッドがベースラインから移動し、保留中のチェックがなく、シグネチャが連続する2回のポーリングで安定した場合に判定を出力します。
- 最終的なstdout行は次のいずれかです:
GREEN: #<n> ready to merge→ ステップ4に戻り、承認してマージします。NOT-GREEN: #<n> settled failures=X mergeable=Y state=Z→ 再分類します。現在はREAL_FAILUREまたはHOLDです。
- オプションの環境変数:
POLL_INTERVAL（秒、デフォルト45）、MAX_POLLS（N回のポーリングで諦める、0= 無制限。枯渇時にNOT-GREEN: #<n> timeout ...を出力）。
ポーループであり gh pr checks --watch ではない理由
gh pr checks <n> --watch は、すでにマージ可能でチェックが実行中のPRには適していますが、このスキルが存在するリベースパスでは積極的に誤解を招きます:
- 古いヘッドでのグリーンで終了します。 リベースチェックボックスがオンにされた直後、PRの_現在の_チェックはすでに終了しています — リベース前（競合）のヘッドで合格しています。
--watchは「保留中のチェックなし」と見なして、Renovateがリベースする前に成功を返します。head moved off baseline条件こそが、この偽グリーンを防ぐためのものです。 - チェックのみを認識し、マージ可能性は認識しません。 GREEN判定には
mergeable=MERGEABLE+mergeStateStatus=CLEANが必要であり、CONFLICTING はこれらのフィールドを介して_検出_されます —gh pr checksはこれらを報告しません。単一のgh pr viewポールは両方を一度にカバーします。 - ヘッドは2回移動する可能性があります（Renovateプッシュ、次にアプリボットのポストアップグレードプッシュ）。それらの間には、既知のチェックが一時的に完了しているウィンドウがあります。
--watchはそのギャップで終了する可能性があります。「保留中なしかつ2回のポーリングで安定」というガードがそれを乗り越えます。
7. リベース後の予想コミットチェーン
リベースチェックボックスがオンにされた後（またはRenovateが独自にリベースした後）、GREENランドは通常、次のチェーンを経由します — これを知っておくと、モニターの変動が障害ではなく期待されるものであることがわかります:
- Renovateが新しいヘッドをプッシュ（
renovate[bot]として）。 pull_requestワークフローが起動します。check.ymlのポストアップグレードステップは、eslint --fix、prettier --write、vitest --update、projen、およびbeachball変更エントリを実行します。- ポストアップグレードステップで差分が発生した場合、
commit-upgrade-changesジョブはactions/create-github-app-token@v2を介してアプリトークンを生成し、<app-slug>[bot]として修正をプッシュします。そのボットプッシュによりpull_requestワークフローが再トリガーされるため、ヘッドが2回目の移動をし、チェックが再実行されます。 - 最終準備完了状態:
mergeable=MERGEABLE、mergeStateStatus=CLEAN、すべてのチェックがSUCCESS/SKIPPED。
ヘッドは2回移動する可能性があるため（Renovate、次にアプリボット）、モニターは「ヘッドがベースラインから移動 + 保留中なし + 2回の安定ポール」に基づいて判定を下し、最初に確認したプッシュには基づきません。
停止条件
- GREEN PRが残っていない — 完了。
- REAL_FAILURE — スキップ、次のPRに進む。REAL_FAILUREを自動リベースしない。
- HOLD候補 — 人間の判断のために表示する。自動マージしない。
- ユーザーがキャンセル。
制約
- コミット件名にIssue/PR参照を含めないこと（プロジェクトルール）。ここではリモートPRのマージには適用されませんが、このスキルがローカルコミットを作成するように拡張された場合は、参照を件名から本文に移動してください。
/create-commitを参照。 - REAL_FAILUREに対してリベースチェックボックスをオンにしないこと。
- HOLD候補を自動マージしないこと。
- HOLD検出は手動チェックリストであり、ハードコードされたルールではありません。上記のカテゴリを認識し、候補を表示してください。判断を自動化しようとしないでください。
テスト注意事項
ドライランの分類
何にも触れずにバケットを列挙して確認する:
gh pr list -R "$REPO" --author "app/renovate" --state open \
--json number,title,mergeable,mergeStateStatus,statusCheckRollup \
| jq -r '.[] | "\(.number)\t\(.mergeable)\t\(.mergeStateStatus)\t\(.title)"'
保留中/失敗チェックを確認するために、PRごとにロールアップサマリーを追加する:
gh pr list -R "$REPO" --author "app/renovate" --state open \
--json number,statusCheckRollup \
| jq -r '.[] | "\(.number)\t" + ([.statusCheckRollup[] | .conclusion // .state] | join(","))'
モニターのスモークテスト
既知のPRに対して偽のベースラインSHA（ヘッドがすでに「移動した」とみなされるように）と短い間隔でモニターを実行し、状態行と最終判定を確認する:
POLL_INTERVAL=2 MAX_POLLS=4 \
scripts/monitor-renovate-pr.sh <known-pr> "$REPO" deadbeef0
シグネチャ変更ごとに1行の状態行、次に GREEN: / NOT-GREEN: の判定が表示されるはずです。PRの実際のヘッドをベースラインとして渡すと、リベースなしのパスがテストされます: ヘッドが移動しないため、安定せず、MAX_POLLS タイムアウトで終了します。
対象外
- ハードコードされたHOLD検出ルール（上記の手動チェックリストとして開始し、後で拡張）。
- このスキルを任意のオーケストレーションレイヤーに配線すること。