最終的には記事にまとめたいけどとりあえずのメモ。

main や develop など壊れると困るブランチへの CI。
対策方法をいくつか載せていますが他にもあったら教えてください。

前提

CI は各 PR で行われておりテストが通らなければマージできない。
つまり保護ブランチで PR またはステータスチェックが必須になっている。

マージブランチ（ベースブランチを取り込んだ状態）でテストを行っている。

ちゃんと CI してるのになぜ壊れるのか？

PR が複数あると各 PR は完璧に運用されていてもマージのタイミングによってはすり抜けることがある。
これは CI がトリガーされるタイミングに起因する。（3. では PR#2 の CI はトリガーされないため PR#1 を含んだ CI は 4. まで実行されない）

1. PR#1: pass
2. PR#2: pass
3. Merge PR#1 into main: pass
4. Merge PR#2 into main: fail
   

対策 1

マージされた時点でそのブランチをベースにしている PR の CI をやり直す。

課題

デフォルトの GITHUB_REF を使用したワークフローの Re-run だと当時のコミットが再現されてしまうので最新で走るようにワークフローを書かなければいけない。

対策 2

ブランチが最新であることを保護ブランチの設定で必須化。

課題

PR の数が多いと最新にするだけでも大変。
Update branch したタイミングでも CI が走るので CI が混雑する。

妥協 1

マージ時に CI を走らせて失敗したらリバートまたは hotfix する。

課題

一時的に壊れることになる。
マージしたタイミングでも CI が走るので CI が混雑する。

妥協 2

1日1～数回各ブランチでテスト。

課題

一時的に壊れることになる。
気付くのが遅くなる。
深夜帯であれば CI の混雑は避けられる。

未調査

マージキューが使える？