renovate

rangeStrategy

デフォルトでまあまあいい感じ

library か app か見てくれて pin する

Pin dependencies if we detect that it's an app and not a library

判定どうやってる?

pin するのは devDependencies だけ

devDependencies だけ automerge

code:dev.json

"packageRules": [

{

"automerge": true

}

]

schedule

結構なんでも書ける

Issue(dashboard) に更新が溜まっていく

code:schedule.json

"schedule": [

"after 10:00 before 18:00 on monday"

]

packageRules の気持ちがわからん

code:packageRules.json

"packageRules": [

{

"groupName": "non-major",

},

{

"automerge": true

}

],

Important to know: Renovate will evaluate all packageRules and not stop once it gets a first match. Therefore, you should order your packageRules in order of importance so that later rules can override settings from earlier rules if necessary.

Docker で動かす

設定でよくわからんエラーが出たときなど

$ docker run --rm renovate/renovate:slim --platform=github --token=<TOKEN> pokutuna/pokutuna-com

他リポジトリの設定を参照していてエラーが出る時は結局分からない

こういう設定がほしい

が、うまく言語化できていないので課題や感想を書き下す

リポジトリが多くて疲れる

仕事で見るのが15個ぐらい? 個人で設定しているのは5つぐらい

個別の PR を手でマージしてられない

通知がめちゃめちゃになる

👉 automerge に寄せたい

👉 groupName で PR まとめたい

1日中 CI 回っててかわいそう

テストが通る != リリースできる

テストの網羅性そんなに高くない

動作確認したい系

これをテストにしていくフローが回るのが理想だけど

触る頻度が低いリポジトリ

常に最新にしたいモチベーションはあまりない

master と topic branch だけの構成になっていたりする

がんがん master に automerge されるのも困る

触るの nヶ月ぶり、という状況がわりとよくある

依存モジュールがめちゃめちゃ上がっている

動作確認してリリースしてから、開発に入れるみたいな感じになる

久々に緊急時に触る状況で色々上がっているとリスキー

Changelog 読む機会がないのも困る

改善の機会に気づけてない

がんばりの問題になる

人によって読まない

👉 major ごとぐらいには見よう、みたいな運用

こういうモジュールは面倒

低レイヤのライブラリ

Changelog からアプリケーションへの影響推測するのに距離がある

クラウドサービスのクライアント

テストではモックされていたりエミュレーターだったり

ちゃんとした E2E テスト or 動作確認してみないとわからないことが多い

React Component ライブラリ

Date Picker が依存する時刻ライブラリの更新によって壊れた

外部コンポーネントライブラリの挙動まであまりテストしない

snapshot 的には変化ないこともある

原因にたどり着くのがムズい

renovate によって発生する作業

PR 見る

PR 見る個数が減れば楽になる

動作確認

モジュールによっては個別のほうが良いかも

実際はドカンとマージして動作確認する事が多い

テスト落ちてたら直す

これは変更範囲が限られてるほうがやりやすい

マージ

PR 少ない方が楽

ボタンぽちぽち

PR 細かく別れてる方がいいこと

1つの変更に1つの PR

revert しやすい

実際そういう細かい revert するかというと疑問

ヤバいときは前の release まで戻す

特定のライブラリ上げて壊れたことに気づいたら

固定する変更を入れる

最新のバージョンで使えるように修正する

changelog 見やすい

pin は勝手にやってくれていい

更新によって挙動が変わる、よく壊れるようになるモジュール

react-router

denylist 的に group の外に追い出したくなりそう

groupName どういう粒度にするか

1つの大 PR

renovate によって上がるやつ全部入りブランチ

そのブランチでテスト通して動作確認してマージ

あまりメンテされないリポジトリならこれでよいかも

major と major 未満

major ごとに changelog 見たいみたいな話

実際 major の PR どのぐらいある?

目で適当に見る 👉 major 4/20

Changelog は見たほうがいい雰囲気ものが多かった

ちなみに minor 5/20

個人開発なら major 未満は automerge でいいかな

major と major 未満 dependencies, major 未満 devDependencies

major 未満の devDependencies は automerge する

仕事ならこれぐらいにするかなあ

default と base ブランチ運用

こういうのはどうか

base(renovate の PR 先)にガンガン automerge していく

テスト落ちるやつだけモジュールごとの PR が残る

default(github のデフォルトブランチ) へ PR 作る

マージ&リリースは base をマージするごとに行う

master マージでリリースするのとも噛み合わせがいい

これ自動化したいが

git-pr-release 的な