GitHub ActionsのCIが9/24から通らなかった件、最大の原因はE2Eの6時間ハングだった

開発eurekapu-nuxt4

GitHub ActionsのCIが9/24から通らなかった件

Excel講座のリポジトリ(eurekapu-nuxt4)で、GitHub Actions の CI のワークフロー欄が落ちていた。 「そういえばね」と切り出して、Claude Code に調べてもらった。

いつから落ちていて、なぜ落ちるのか。 頼んだ時点では、どちらも分かっていなかった。

最後に通ったのは 9/24

調べてもらうと、原因は3種類に分かれていた。 まず、6時間でタイムアウトした回がどのステップで止まったのかを追ってもらった。

次に出てきたのは日付だった。 CI が最後に通ったのは 9/24 で、それ以降は一度も成功していない。 そこから何が変わって落ち始めたのかを確かめてもらった。

目星がついたのは、9/26 のコミット b9b404ac である。 dev scene API の子プロセスを detached にした変更で、続けて裏付けも取ってもらった。

毎回6時間ハングしていた E2E

3つの原因のうち一番の問題は、このコミットが入れた E2E のハングだった。

  • 9/26 の夜から14回、E2E がハングしていた
  • どの回も、6時間でタイムアウトするまで止まらなかった
  • そのたびに、Actions の分数を大量に使っていた

提案された対応には「OKで進めてください」と返した。 あわせて、メモを残すように頼んだ。

今回の対応については、メモに一応残しといてくださいね。これ原因が何だったかと、どういう対応をするかについて。

修正前の失敗を手元で再現してから直す

修正は、失敗を手元で再現するところから進めてもらった。

  • E2E のハング:修正前は watcher が残り、修正後は終了することを再現で確かめた
  • ユニットテスト:修正し、通ることを確かめた
  • トップページの E2E:手元で実行した

最終的な報告は「3件とも直した。どれも修正前の失敗を手元で再現したうえで、直ったことを確認した」というものだった。 ハングしたまま走っていた実行 37077625510 も、キャンセルしてもらった。

ただし、この時点ではまだコミットも push もしていない。 手元で直っても、CI 上で最後まで通るかは未確認のままだった。

追加で付けた timeout-minutes: 60

修正の報告のあと、もう1点付けるかどうかを聞かれ、「はい、つけといてください」と答えた。 こうして付いたのが timeout-minutes: 60 である。

今回の修正でハングは解消したはずだ。 それでも別の理由で E2E が固まれば、今度は6時間ではなく60分で打ち切られる。

コミットと push、そして CI の結果待ち

修正3件、メモ、timeout-minutes: 60 をまとめて、コミット 6d2a2586 にしてもらった。 コミット時の Codex レビューでは、critical と high の指摘は出なかった。

push すると、未 push だった Excel 関連のコミット5件(a34a19fa〜abe9d83a)も一緒に上がった。 CI(実行 37091438289)が動き始め、終わるまで約30分かかる見込みだった。

ここで「このセッションもう終わりにしても大丈夫ですか?」と聞いた。 答えは、終わりにしても大丈夫だが、CI はまだ走っている途中で、通るかどうかは確認できていない、というものだった。 メモの「CI が最後まで通ることを確認する」も、未チェックのまま残っている。 セッションを閉じれば、結果を待っている処理も止まる。

9/24 以来はじめて CI が通ったのかどうかは、このセッションの中では分からないままだった。

学びメモ

  • CI の失敗を放っておくと、ハングした回が毎回6時間ぶんの Actions の分数を使う。ジョブに timeout-minutes を付けておけば、打ち切りまでの時間に上限を決められる
  • 最後に CI が通った日(9/24)を起点に変化を追って、原因のコミット b9b404ac に行き着いた
  • 修正前の失敗を手元で再現してから直すと、「直った」と言える根拠が手元に残る

残っていること

  • CI(実行 37091438289)が最後まで通ったかを確認する
  • 確認できたら、メモの「CI が最後まで通ることを確認する」にチェックを入れる
#GitHub Actions#CI#E2E#Claude Code#eurekapu-nuxt4