# 「マージしたのに直らない」— デプロイ元ブランチと定期実行ブランチが違う罠 ## 誰向けか 1つのリポジトリで **Web アプリ本体**と**定期バッチ（GitHub Actions の `schedule`）**の両方を動かしていて、 かつ**本番デプロイ元が `main` 以外のブランチ**になっているチーム。 ## 症状 バグを直して PR を出し、CI も緑、本番ブランチにマージしてデプロイもした。 なのに**毎晩のバッチだけ古い挙動のまま**。ログを見ても新しいコードが動いた形跡がない。 「デプロイが反映されていないのでは」と本番を何度も再デプロイして時間を溶かす。 ## 原因（仕様であってバグではない） GitHub Actions の `on: schedule` は、**常にリポジトリのデフォルトブランチのワークフロー定義で起動する**。 さらに `actions/checkout@v4` を `ref:` 無しで書くと、**そのデフォルトブランチをチェックアウトする**。 つまり実行されるスクリプトの実体は「デフォルトブランチ版」。 本番デプロイ元が別ブランチ（例: `release`、`prod`、`cost-opt` など）だと、**同じファイルの中身が2つ存在し、 アプリは片方、定期バッチはもう片方を使う**という状態になる。 ブランチが長く分岐しているほど中身の差は開く。実測例では、片方だけに167コミット・もう片方だけに201コミットあり、 問題のスクリプトは**デフォルトブランチ側の方が新しかった**（＝本番デプロイ元の方が古い）。 この状態で「本番ブランチを土台に」直すと、**古い版への変更**を作ったうえに**定期バッチには一切効かない**という二重の空振りになる。 ## 検出手順 ### 1. 定期実行がどのブランチで走っているかを確認する ```bash gh run list --workflow=<ワークフロー名>.yml --limit 3 \ --json headBranch,status,conclusion,createdAt,databaseId \ -q '.[] | "\(.createdAt) \(.headBranch) \(.status)/\(.conclusion) id=\(.databaseId)"' ``` `headBranch` がデフォルトブランチになっていれば、この罠の条件を満たす。 ### 2. デフォルトブランチと本番デプロイ元を確認する ```bash gh repo view --json defaultBranchRef -q .defaultBranchRef.name ``` ### 3. 触ろうとしているファイルが2ブランチで食い違っていないか調べる（着手前に必ず） ```bash # 分岐の大きさ git rev-list --count origin/<デフォルト>..origin/<デプロイ元> git rev-list --count origin/<デプロイ元>..origin/<デフォルト> # そのファイルの最終更新がどちらが新しいか git log -1 --format="%ad %h %s" --date=short origin/<デフォルト> -- <パス> git log -1 --format="%ad %h %s" --date=short origin/<デプロイ元> -- <パス> # 中身の差 git diff origin/<デフォルト> origin/<デプロイ元> -- <パス> --stat ``` ### 4. そもそもその列/機能に触っているのはどちらの版かを確かめる ```bash git grep -n "<関数名や列名>" origin/<デフォルト> -- scripts src git grep -n "<関数名や列名>" origin/<デプロイ元> -- scripts src ``` 片方で 0 件なら、**その処理は片方のブランチにしか存在しない**。 「本番で動いているはず」という思い込みが、ここで崩れる。 ## 対処のルール（これだけ覚える） | 触るもの | base にすべきブランチ | |---|---| | `.github/workflows/` 配下 | **デフォルトブランチ** | | 定期バッチが実行するスクリプト（`scripts/` 等） | **デフォルトブランチ** | | Web アプリ本体・API・アプリ内 cron ハンドラ | **本番デプロイ元ブランチ** | 着手前に「このファイルは誰が実行するのか」を1回だけ問う。`schedule` から実行されるなら base はデフォルトブランチ。 ## 直ったことの確かめ方（デプロイ完了は証拠にならない） **新コードにしか存在しないログ行を1本仕込み、実行ログにそれが出たことを確認する。** ```ts console.log(`結果: 更新=${updated}, 無効化=${deactivated}, <新機能名>: ${newCount}件`); ``` ```bash gh run view --log | grep -iE "<新機能名>|結果:" ``` この行が出ていれば、その実行が新コードだったと**断定できる**。 「マージした」「デプロイした」「CI が緑だった」はいずれも “定期実行が新コードを使った”ことの証拠にならない。 ## 応用: 逆方向の事故を先に防ぐ 片方のブランチにしかない「上書き処理」がある場合、将来ブランチを揃えた瞬間にそれが有効化される。 例えば「DB の値をシートの値で無条件に上書きする同期」がデプロイ元ブランチにだけ存在するなら、 デフォルトブランチへ寄せた瞬間に**手で直したデータが元に戻る**。 ブランチを統合する前に、`git diff` で**上書き系の処理が増えないか**を必ず見る。 ## 根本対処 - 本番デプロイ元をデフォルトブランチに一致させる（最善） - できないなら、ワークフローに `ref:` を明示して意図を固定する ```yaml - uses: actions/checkout@v4 with: ref: <本番ブランチ> ``` この1行があるだけで、読む人が「どちらの版が動くのか」で迷わなくなる ---