Cloud Build が push で発火せず、手動実行もできず、Couldn't read commit まで出た状態を切り分けた記録。結局は Cloud Build Repositories（2nd gen）で GitHub host connection を作り直して復旧しました。
GitHub に push しても Cloud Build が発火しない。さらに Cloud Console から手動実行しようとしてもブランチ候補が出ず、エラーとして Couldn't read commit まで出る。
結論から言うと、今回の復旧は **Cloud Build の Repositories（2nd gen）で GitHub host connection を作り直し、対象リポジトリを Link し直す（再接続する）**ことで解決しました。
同じ症状に当たったときに最短で前に進めるよう、原因の当て方と再発防止の型をまとめます。
この手の問題は、次の 3 つが混ざると一気に難しくなります。
「トリガーが悪いのか」「ビルド定義が足りないのか」「権限が足りないのか」を分けて見るのが最短ルートでした。
今回の困りごとは、ざっくり次の 3 つが同時に起きていた点です。
Failed to trigger build: Couldn't read commit が出ることがある途中では「トリガー編集画面で ^main$ に一致するブランチが 0 件」なども見えましたが、今回の本質は「正規表現が間違っていた」より Cloud Build 側が GitHub のブランチ/コミットを正しく参照できていない状態に寄っていました。
この手の障害は「どこで止まっているか」を特定すると一気に楽になります。
cloudbuild.yaml が意図したゴール（例: Cloud Run デプロイ）まで行っていない／途中で落ちる今回の Couldn't read commit は少なくとも「ビルドの中身」以前（= ビルドを作る入口）で躓いているサインでした。
Couldn't read commit が出るのか（公式の説明 + 実感）Cloud Build の公式トラブルシューティングでは、Failed to trigger build: Couldn't read commit は「存在しないブランチを指定したときに返る」旨が書かれています。
ただ今回の体感としては、ブランチ自体は GitHub に存在しているのに、Cloud Build 側がそれを参照できず “存在しない扱い”になって落ちているように見えました。
なので、このエラーは「ブランチ名のタイポ」だけでなく、**接続の壊れ（GitHub App の権限・トークン・Webhook・同期不良）**まで含めて疑うのが安全だと思います。
今回の復旧手順はシンプルで、やったことは「接続を作り直して、見える状態に戻す」でした。
Repositories（2nd gen）**で GitHub の host connection を作成^main$）を設定して push で動作確認公式ドキュメント上、第2世代の接続では Cloud Build GitHub App を認可して接続を作り、認可情報（トークン）を Secret Manager に保持して利用する、という流れになっています。
今回効いたのは「トリガーの正規表現」ではなく、“Cloud Build が GitHub の情報を取れる状態”を作り直した点だと解釈しています。
（逆に言うと、接続が壊れた状態のままでは、どれだけトリガー設定をいじっても「ブランチが見えない」「commit が読めない」から進めない、ということでした。）
切り分けが遅れるのは、だいたい「別の層の問題」を疑っているときだ。今回の型に当てはめると、次は優先度を下げてよかった。
| 疑いがちな原因 | 今回の症状との相性 | コメント |
| --- | --- | --- |
| cloudbuild.yaml が壊れている | 低い（手動実行の入口で止まる） | トリガー以前にブランチが見えないなら、まずソース接続 |
| ブランチ正規表現が誤り | 中 | ^main$ は直すが、接続不良だと「0 件」に見えるので単体では決め打ちしない |
| Cloud Run の権限不足 | 中〜高（別フェーズ） | ビルドが始まってから疑う。commit が読めない段階では後回しでよい |
| GitHub の Webhook 設定を手でいじる | 2nd gen 運用では迷子になりやすい | 公式の「Repositories 接続」側を正として追う |
用語が多いので、どの画面を開けばいいかだけメモする（プロジェクト名やリポ名は書かない）。
次に同じ症状に当たったら、私はこの順で確認します。
.* ではなく ^main$ に寄せる.* は意図しないブランチでも走る（コスト・事故・デバッグ難易度が上がる）^main$ のように絞るのが基本cloudbuild.yaml 側に deploy が必要トリガーが動いても、cloudbuild.yaml が npm run build で終わっていると Cloud Run は更新されません。
Cloud Run まで自動で更新したい場合は、少なくとも次の流れが必要です。
gcloud run deploy（または同等）でデプロイ接続を作り直したら、次の 3 点を満たすまで「直った」と言わない方が安全だった。
main（または対象ブランチ）が出る今回の結論は、「トリガー設定が間違っていた」というより Cloud Build が GitHub のブランチ/コミットを参照できない状態になっていたことでした。
push で発火しない／手動実行もできない／Couldn't read commit が出る、が同時に起きたら、まずは Cloud Build Repositories（2nd gen）で host connection を作り直して再リンクするのが、結果的に一番早い復旧手段になりました。
dairy-snap を Docker / Cloud Build / Cloud Run 気味に寄せるときに踏んだ地雷の型。standalone、prisma generate、Node heap、ダミー DATABASE_URL、PORT。04-16 前後のコミット列を軸に、個人開発でもハマる点を整理する。
RenderからGCP Cloud Runへの移行、Neon PostgreSQLへの移行、GitHub連携による継続的デプロイの実装について
天気（Open-Meteo）と Google カレンダーのキャッシュ・分類が、日記と AI の文脈にどう効くか。entry-weather・WeatherAmPmDisplay・weather-tool などコード上の出所と、設計意図・本番運用をまとめる。
Google OAuth・許可リスト・JWT セッションの方針と、middleware から proxy へ寄せた経緯。HTTPS 背後での secureCookie、Docker 本番との相性。04-17 前後のコミットを手がかりに。
daily-snap の画像アップロード。最大辺2048px、AVIF優先（非対応ならWebP）の圧縮、ストレージ抽象と本番 GCS 前提。日記アプリで画像が重い問題への殴り方。
AI チャットの SSE（ストリーミング）をローカル・本番で確認した手順と、環境差分で再発しうる罠。ai_artifacts / audit_logs を厚くする理由と、本文をサーバログに出さない方針。