このページでわかること
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がログに出ている、権限変更が必要、テスト無効化に進みそう、危険操作が必要な場合。
FAQ
CI失敗はCodexで直せますか？
原因候補の整理や小さな修正は任せやすいですが、最終確認は人間が行います。
ログは全部貼ってよいですか？
Secretsやtokenが含まれないことを確認してから扱います。
テストを無効化して通してよいですか？
推奨しません。原因を確認して必要な修正をします。
どこから読みますか？
落ちたcheck名、失敗箇所、関連ファイル、直近差分を見ます。