renovate minorやpatchアップデートををまとめないように

[youchann]

これはjust ideaですので、議論大歓迎。

#435 のようにスタックしがち。
やるには腰が重くなりがちなので、PRをまとめないように設定を変更する。

[netlify]

✔️ Deploy Preview for ingred-ui ready!

🔨 Explore the source changes: 5e999f8

🔍 Inspect the deploy log: https://app.netlify.com/sites/ingred-ui/deploys/613026c493fccb0007cd44b6

😎 Browse the preview: https://deploy-preview-437--ingred-ui.netlify.app

[kohashi]

なんらかのグループ化、または patch バージョンだけはまとめるとかしないとPR溢れて大変になるのでは？ 🤔
という気もしますので、難しいとこですね…。

#435 のコケた理由は snapshot の不一致で、 styled-components の生成する乱数が変わった感じだからなのかな？
てかこの class="sc-乱数" の 乱数はなんかの種があるのかな。
ちょっとわかってないけど、理由がstyled-components なら renovate分割してもあんま関係なさそうな（問題の切り分けがしやすい！というのはありそうか）

[ryokosuge]

なんらかのグループ化、または patch バージョンだけはまとめるとかしないとPR溢れて大変になるのでは？ 🤔

これは自分も同じ気持ちしましたが、1つずつ対応しないで一気に（1つずつのPRを）確認することを考えると別々のPRで1つずつ確認できる方が確かにやりやすそうだなって思いました！
一気にというかまとまった時間内で全部を確認するって感じですね

[youchann]

#435 くらいまとまってしまうと、各々のリリースノート追うのに時間がかかるので「とにかくCI通してリリースする」のが最優先になってしまうのですよね(自分はそうだった)。

あるべき状態は、各packageのアップデートをキャッチアップしてそれを現リポジトリに反映させることだと考えておりまして。(それと似た思想があってgithubネイティブなdependabotはPRをまとめる機能がない)

なので分けてしまおうかな。という背景もあります！！

[youchann]

とはいえpatchまで入れるのか？には議論の余地があります。(管理画面のほうはpatch を追わないようにしてちょうどよく回ってきている)

[kohashi]

なるほどこのへん。
https://github.com/voyagegroup/fluct_ms/blob/master/renovate.json#L13-L14

Patch Version 追う/追わないみたいなの難しいですねー。
たいていは「一部のバグ修正・セキュリティ上の修正」なのでむしろ積極的に取り込みたいような気もするし、それはそれで「知らない間にバグ混入」とかありそう。

"patch": { "automerge": true }, 　とかで「CIでチェック通ったらマージ」とするのもありえそう。
いまググったらリクルート傘下のスタディサプリが同様にしている
https://tech.recruit-mp.co.jp/front-end/post-21350/

[kohashi]

とりあえず「minorは分割する」の部分は賛成です！

[youchann]

ああ、patchは自動でマージ、minorは分割。みたいな方針で良さそう。

[youchann]

↑で一旦どうでしょう....?

[youchann]

@kohashi @ryokosuge ↑どうですかねー:thinking:

[ryokosuge]

@youchann

patchは自動でマージ、minorは分割。みたいな方針で良さそう。

いいと思います！賛成です！

[kohashi]

👍
まぁこれも運用してみて「うーん」ってなったら再調整だし、とりあえずの方針としては :LGTM: です！

[youchann]

了解ですー、ではその設定にしてマージしておきます！