← ishizakahiroshi.com
失敗談 2026-07-22

gh run watch の tail 表示を信じたら、Validate が赤いままタグを push していた話

CI の緑チェックを信じてタグを push したあとに Validate の失敗に気づく場面のヒーロー画像

自作の多 AI コーディング CLI ラッパー many-ai-cli の v0.5.1 をリリースした日の記録です。gh run watch --exit-status が exit 0 で戻り、tail には Complete job の緑チェックが並んでいたので「全部緑」と判断してタグを push したところ、Validate ワークフローは実際には failure でした。実害はゼロで済みましたが、なぜ誤読が起きたのか、なぜ助かったのか、そして自作の release スキルに何を書き足したのかを整理しています。

note で読む → many-ai-cli (GitHub) →

この記事のテーマ

gh run watch の tail に流れる緑チェックは、ワークフロー全体の結果ではなく「最後に完了した個別ジョブ 1 つ」のログです。並列ジョブの中に赤があっても tail には映りません。全体判定は gh run view <id> --json status,conclusion で明示的に取る必要がある、というのが 1 つ目の結論です。

もう 1 つは、Validate が失敗したからといって機械的にリリースを止めるのが正解ではない、という話です。今回赤かったのは third-party notices のバージョン表記 drift 1 ジョブのみで、新規依存もライセンス変更もゼロでした。走行中の goreleaser を途中で殺すほうがアーティファクトを中途半端に残すリスクが高い、と判断して完走させています。Release ワークフローが Validate に依存せずタグで独立発火する設計だったことにも救われました。失敗の中身を build/test/security 系と notice/lint/format 系に分けて扱う、という判断基準を release スキル側に明文化しています。

図解

記事の要点をまとめたインフォグラフィック
記事の要約(tail 誤読・実害ゼロの理由・スキル改訂 4 点)
tail に見える緑チェックと JSON の conclusion が食い違っている様子の挿絵
挿絵: tail 表示と JSON conclusion の対比