すべてのユースケース

詰まったPRがリリースをブロックする前に検知

ZeroがGitHubマージキューを監視し、PRが詰まっている原因を診断し、適切な担当者にアラート — リリースパイプラインが音もなく止まることはもうありません。

Zeroの接続先:GitHubSlack

なぜリリースパイプラインが止まっても誰も気づかないのか

PR #9842がマージキューに2時間入っています。CIはPRの変更とは無関係な不安定なテストで失敗し続けています。後ろにさらに3つのPRが積み上がっています。全員が自分の作業に没頭しているため誰も気づかず、GitHubはPRがキューで詰まっても通知を送りません。リリースがブロックされています。午後4時に誰かが気づく頃には、その日のデプロイウィンドウの半分が過ぎています。Zeroは数分でこれを検知します。

Zeroにマージキューの監視を頼む方法

@Zero vm0-ai/vm0のマージキューを監視して。CI失敗で30分以上キューに入っているPRがあれば、失敗原因を診断してPR作成者にSlackでアラートして。

Zeroが詰まったPRを検出・診断する仕組み

Zeroがスケジュールでマージキューを確認
ZeroがGitHubのマージキューAPIを検索し、キュー内の各PRを調査 — 待機時間、CIの通過状況、後ろのPRをブロックしているかどうかを確認します。
Zeroが詰まったPRの原因を診断
キューに入りすぎている、またはチェックが失敗しているPRについて、ZeroがCIログを読み取り、具体的な失敗テストやチェックを特定し、PRの変更に関連しているか、既知のインフラ問題かを判断します。
Zeroがアクション可能なコンテキスト付きで適切な担当者にアラート
一般的な「PRが詰まっています」の通知ではなく、ZeroがSlackに詳細な診断結果を投稿します:どのチェックが失敗したか、なぜ失敗したか、誰がPRを作成したか、何をすればブロックが解除されるか。適切な担当者が見て行動できる — 調査作業は不要です。

パイプラインを流れ続ける状態に保つ

失敗したCIチェックを再実行
Zeroに不安定なテストをクリアするため、特定の失敗チェックの再実行を依頼します。
@Zero PR #9842のcli-e2e-03-runnerチェックを再実行して
既知の不安定なテストをホワイトリストに登録
Zeroにどのテストが不安定かを伝えて、過剰なアラートを防ぎます。
@Zero cli-e2e-03-runnerは既知の不安定なテストとして記録して — 3回連続で失敗した場合以外はアラートしないで
定期実行にする
チームのPR速度に合わせてマージキュー確認をスケジュールします。
@Zero 毎日正午と午後4時にマージキューを確認して、詰まったPRがあれば#devにアラートして

必要な連携: GitHubとSlack

GitHub
GitHub
GitHub — マージキュー、CIチェックステータス、PR詳細への読み取りアクセス。失敗したチェックの再実行にはオプションの書き込みアクセス。
必須
Slack
Slack
Slack — 診断詳細付きのマージキューアラートをエンジニアリングチャンネルに投稿します。
必須

マージキュー監視のベストプラクティス

チェック頻度はチームのPR速度に合わせて設定してください — 高速なチームは毎時チェックが必要ですが、ほとんどのチームは1日2回で十分です。
既知の不安定なテストのリストを管理し、Zeroにアラートから除外するよう伝えましょう。これによりアラート疲れを防ぎ、シグナルの質を保てます。
auto-merge-releasesと組み合わせて完全なリリースパイプラインに:merge-queue-monitorが詰まったPRを検出し、auto-merge-releasesがキューが空いたらリリースを出荷します。