このページでわかること
GitHub Actionsの失敗を、lint、test、build、依存関係、権限、Secretsの観点で切り分ける流れがわかります。
結論
CodexにGitHub実務を任せる時は、対象repo、branch、差分、Secrets、CI、PR本文を分けて確認します。main直push、危険操作、テスト無効化、private repoなら安全という考え方は避けます。
対象読者
CodexでGitHubのIssue、PR、レビュー、CI、branch、private repo、READMEやrelease noteを扱いたい人向けです。
Codexに任せやすいこと
失敗checkの特定、ログ要約、修正候補の分類、再実行前の確認リスト作成。
人間が確認すべきこと
CIを通すためにテストを無効化していないか、Secretsがログに出ていないか、修正範囲が小さいか。
GitHub作業での注意点
ログの最初と最後だけで判断せず、該当check、失敗箇所、再現条件、環境変数の扱いを分けます。
やってはいけないこと
危険コマンド、force pushの安易な推奨、テスト無効化、Secretsやtokenのログ出力、社内コードや顧客情報の入力推奨は避けます。
STOP条件
Secretsがログに出ている、権限変更が必要、テスト無効化に進みそう、危険操作が必要な場合。
失敗のログは、最後から読まない
ログを開くと最後にエラーが出ているので、そこから読みたくなります。ですが最後の行は、たいてい結果であって原因ではありません。読む順番を変えるだけで、原因に着く速さが変わります。
- 最初に失敗した工程を探す。後の工程は、前が失敗した結果として連鎖しているだけのことがあります
- その工程の最初のエラーを読む。同じ種類のエラーが何十行も続いていても、原因は先頭の1件です
- 直前に何が変わったかを見る。昨日まで通っていたなら、変わったものは限られています
そして「手元では通る」場合は、環境の違いを疑います。実行する場所が違えば、使える道具の版も、扱える文字も、大文字小文字の区別も変わります。手元で再現しないことを理由に「たまたま」と片付けると、同じ失敗が続きます。
直す範囲を先に決める
失敗を直すときに範囲が広がるのは、原因の特定と、ついでの整理を同時にやってしまうためです。分けてください。
- まず通す。原因に対する最小の修正だけを入れ、通ることを確認します
- 整理は別にする。気になった箇所は記録しておき、通ってから別の作業として扱います
- 設定そのものを緩めない。失敗する検査を無効にすれば通りますが、それは直したことになりません
3つ目は誘惑が強いところです。検査を外して通した状態は、通っているように見えるぶん、外したことを忘れます。どうしても一時的に外すなら、いつ戻すかを同時に書いてください。
また自動で走る処理を止めるときは、止まったことを確認してください。呼び出し元を終わらせただけでは、そこから起動された処理が生き残ることがあります。止めたつもりで動き続けている状態が、いちばん分かりにくい失敗です。
FAQ
CI失敗はCodexで直せますか？
原因候補の整理や小さな修正は任せやすいですが、最終確認は人間が行います。
ログは全部貼ってよいですか？
Secretsやtokenが含まれないことを確認してから扱います。
テストを無効化して通してよいですか？
推奨しません。原因を確認して必要な修正をします。
どこから読みますか？
落ちたcheck名、失敗箇所、関連ファイル、直近差分を見ます。