GitHubで1PR中のファイルが301以上あると、CI連携のファイルパス実行判定がうまくいかない
タイトルでぜんぶ言おうとしたんですが、さすがに無理でした。
CI連携として現象を確認したのはGitHub ActionsとGoogole Cloud Buildです。他のCI連携でも発生する可能性はありそうですが特に試していません。
現象
具体的にはこの確認用repositoryとcommit、そのworkflows状況を見てもらうのが早いです。last commit 2ヶ月前なのは気にしたら負けです。
状況を要約すると以下のようなものです。
- 全部でa~zまでの26 dirがあり、各dirごとにpathを見て実行されるworkflowが26個ある
- 上記commitでは、各ディレクトリにつき20ファイル分(26 * 20 = 520 files)をcommitした
- その結果、実行されたworkflowはa~oのディレクトリ用の15個(15 * 20 = 300files)だけで、p~zのディレクトリを対象とした残りのworkflowは実行されなかった。
この現象は1ディレクトリごとの変更ファイル数を変えてももちろん発生します。
たとえば、1ディレクトリごとに100ファイルの差分を入れると、a,b,cのworkflow までしか実行されません。
つまり、現象としては CI連携時にファイルパスによって実行判定をしている場合、判定に使われるのはフルパスでアルファベット昇順の300ファイルまでで、それ以降は無視される ということです。
どういうときに困るのか
正直 1 commit 300 overのファイル更新をしてたらcommitを分けろという話なんですが、問題はPR mergeの場合にも発生するということです。
なので例えば、
- 最近流行りのmonorepo
- serviceごとにtop directoryを分けており、それごとにCI/CDが回っている
- PRのmergeがリリースのtriggerに利用されている
- 複数serviceの変更が1プロジェクトとしてまとめてmain -> releaseブランチにmergeされる場合がある
みたいな状況において、名前が昇順で前半になるserviceが多数のファイル更新をしていると、名前が降順で後半のserviceに設定されたCIが実行されなくなります。
厄介なところは、問題が発生するのがservice数やworkflow数などを作り込んだあと、1リリースあたりの開発量が増えてきた段階でぶち当たるところでしょうか。
差分ファイル数はあんまり計測しないと思うので なんか今回リリースうまく動かなかったね？というのがまれに起こる みたいな調査対応のコスパが悪い事象が起きるのが面倒かなと思います。
対応
現在自分が所属している会社では、monorepoを採用しつつ 2 week release cycleで回しているのですが、deploy triggerにmaster -> stg -> prod ブランチへ release PR mergeを使っており、service数が増えてきたところでこの問題が頻発するようになりました。
今は一旦、root dirに _EDIT_TO_KICK_BUILD みたいなtrigger fileを用意することでリリースのときに一通り必要なservice deployを実行するようにして回避しています。
ただ、本質的にはリリースフロー自体を変える必要があるとは思います。
ちなみにGitHubには報告してみたんですが、「多分タイムアウトかなにかだけど、そんなまとめて処理しないでね。priorityあげづらそうなんでissueにはしないね。」というお返事を頂いてしまったので、当面は仕様と受け入れる必要がありそうです。
自分の英語が伝わらなかっただけかもしれません。
ついでに宣伝
こんな問題にぶつかったりしていますが、弊社まだ開発者4名(+業務委託数名)という体制で、2weekで毎度数百ファイルってだいぶすごい開発量だな〜〜って思いながら横で見ています。 (自分は主にインフラ/SREなので除外...)
一人あたりの生産性は恐ろしく高い人達だと横で見ていて思いますが、とはいえまだまだ人が足りません。
リリースサイクルの話も乗ってるので、気になった方はぜひページの資料だけでも見ていってくださいそしてぜひお話しましょう！！！
あ、ちなみに別にこれは会社の名義/立場で書いているわけではないです。念のため。
Discussion