Renovateを導入する

[qryxip]

内容

Renovateを導入します。

#289で私は「Deps.rsのバッジが黄色くなったタイミングで手動でアップデートするのがちょうどいいのではないか」ということを言いましたが、今現在の状態のように、PRが溜まるとちょうどよいタイミングというのが中々訪れません。そのような状況でも有無を言わさずPRを自動的に作ることで、「やるべきタスク」として可視化するという効果が期待できるのではないかと思いました。

Renovateは聞いている限りだとRustとの相性も悪くないようです。Renovateの設定は多岐にわたるようで、 複数のパッケージの更新を一つのPRにまとめたりできるようです(例)。update_rust_toolchainもRenovateに一本化できそうです(例)。

Pros 良くなる点

• 依存ライブラリの更新を、「やるべきタスク」としてPRという形で可視化できる
• 更新を忘れがちなGitHub ActionsのActionも、自動的に更新のPRを受け取れる
• Renovateはリリースノートも抽出してくれてPRの本文で教えてくれる
  • ライブラリ数十個分のリリースノートを見に行くのは正直ちょっとだるいので、これは助かるかも

Cons 悪くなる点

なし (PRの頻度をほどほどに抑えるという前提だと)

実現方法

私はまだRenovateを使った経験がないので、まずは私個人で実験をしつつ、丁度よい塩梅の設定を発見したらPRを作成する。

RustのOSSではあまりRenovateの採用を見ない(Depedabotなら見る)のですが、ArkEdge Space Inc.のOSSと、そこのCI周りを設定しているであろうsksatという人のRustリポジトリとかが参考になるかなと思っています。
(地上で動くHTTPサーバーだろうが宇宙に飛ばすマイコンだろうがほぼRustで統一している会社らしいとのことで、以前から存在は知ってました)

我々は Rust というプログラミング言語の生産性を信じており，OBC のデバイスドライバや高信頼性が必要な地上のシステムなど，ミッションクリティカルなソフトウェアはすべて Rust で開発しています． そして，それが持続できるように，日常的に Rust を書くエンジニアを増やしていきます．

さらに，今後我々が開発するすべての OBC は，Rust が実行可能になります． つまり，Rust が動作しないマイコンは，我々は決して採用しません．

VOICEVOXのバージョン

N/A

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

[Hiroshiba]

なるほどです。
依存バージョンの更新は結構後回しになりがちですが、コアはテストが結構書かれているのでそこそこの頻度で更新してもよいのかなと思いました。
そういったツールの導入も試してみたいところです。

２〜３ヶ月に１回アップデートとかが良いかもですね！
あと、個人的にはrust toolchainの更新頻度も下げていいかなと思っています。
同じタイミングでtoolchainとcargo.tomlを更新するのはどうでしょう。
（特に使いたいものも無く、そのPRを毎回見るのもという感じなので･･･。
使いたい機能がある場合はアップデートするのはありだと思います）

[qryxip]

うーん私は月5〜10回のPRが飛ぶくらいの調整を考えてました...
(rust toolchainとかはCIが通ればautomergeしたりしながら)

(6週間おきの)RustのリリースごとのPRで、CIが通ったら強制的にautomergeというのはどうでしょうか?

[Hiroshiba]

なるほどぉ。
いろいろちょっと整理してきました。

まずそもそもライブラリを追従するですが、「脆弱性などがあったときにライブラリを更新しやすいため」だと思います。
また、ライブラリを更新するのはメンテナー的にはどうしても手間で、かつ自動PRはGithubでの検索効率を落とすので生産性が逆に下がると考えてます。

であれば、更新が億劫にならない中で一番長い頻度で、自動PR（可能ならautomergeも）が来るのが一番いいのかなと思いました！

で、おそらく追従が結構めんどくさくなりがちなライブラリで一番更新頻度が高いのは、VOICEVOX全体でelectronが該当しそうでした（要検証）。
electronのアプデ頻度は大体２ヶ月に１回です。（ちなみにEOLは半年強っぽかったです）
なので、VOICEVOX全体的に、２ヶ月に１回の頻度（例えば奇数月の1日目）でライブラリをアップデートすると良いのかなと思いました！！
（６週間や８週間でも良いのですが、２ヶ月に１回にしておくとイベントとして認識しやすくできそうなのでありかなと）

コアのライブラリもこの頻度が良いと思いましたが、どうでしょうか。
（Rustなどの言語自体のアップデートは、本来はパッチアップデートが出たタイミングが良さそうに思います。）

[Hiroshiba]

さらに「こういうことができればいいな～」と思ったアイデアがあったのでメモです。

最新版に常に保ち続けるのは必ずしも正解ではないと思ってます。
というのも、最新版のライブラリにしかないようなバグを踏んでしまう可能性があるからです。
これは3日後に修正されるかもしれないけど、その3日間はバグってしまいます。

例えば2週間より前に出ているマイナーバージョンの最新版を取って来れるとこの問題を回避できそうだなとか思いました。
Renovateにそういう機能があれば非常に嬉しいかもです。
（まあでも2ヶ月に1回ならそんなこと気にせずに全部最新版アップデートでもまあ別に良さそう。）

[qryxip]

update_rust_toolchainの置き換えとしてだけRenovateをお試し、というのもいいのではないかと最近思っています。

[Hiroshiba]

Renovateが導入されました 🎉

が、動いて無さそう･･･？

[qryxip]

私の権限で設定画面を開けたのですが、dry-run的なモード(Silent)になっているっぽい...?

[Hiroshiba]

@qryxip ありがとうございます！！！なんかそっぽい気がしてきました！！
今からモード変更してみたいと思います。

[Hiroshiba]

runしたら60個くらいのプルリクエストが開かれそうになったので、1回権限を剥奪しました！！ 🙇

[Hiroshiba]

Renovate再度ONにしてみます！

[Hiroshiba]

おーーーー！！うまいこといってそうですね！！！

• Update dependency Rust to v1.73.0 #639

Renovate Updates一覧を見ても良い感じっぽかったです。Actionsもアプデ検知してくれてそうで便利そう。

[Hiroshiba]

ちょっと相談させてください！

force pushのたびに通知が飛んできていて、多分このままだと通知で疲弊してしまうデメリットが大きいかもと感じました。
もちろんメリットとして、どれぐらいの差分があるのかがわかるのは良いことだと思いますが･･･。
メンテナはおそらく無視するようになってしまい、あと個人的には特にこのリポジトリをウォッチしてる人にネガティブになってしまうのが気になってます。

確かアップデートの頻度を2ヶ月に1回目標にしている感じでしたっけ。
であれば2ヶ月に1回プルリクエストが来る形でも目標は達成できるのかなと感じました。

もちろんそれ以外の思いがあると思うので、コメントで相談させていただいた次第です！！
良い落としどころがあればいいのですが･･･。
譲れないポイントとか覚えとかあったら知りたいです！
（例えばボットに対する通知を切れば良いはずとかでも。）