okaryo.log

今さらrenovate使ってみた | okaryo.log

今さらrenovate使ってみた

    #renovate#CI/CD

はじめに

いろんなGitHubリポジトリを見ていると、コントリビュータの欄にrenovateというbotが表示されているのをよく見かけていた。

そんな折、個人で開発しているツールの依存ライブラリを久々に更新することがあり、手動での作業がとても面倒に感じたので自分もrenovateを使ってみることにした。

設定方法

まずはGitHubAppのrenovateをインストールする。

Build software better, together
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
favicongithub.com
ogImage

インストールが完了すると、早速renovateが設定ファイルを作成してPullRequest(以下PR)をリポジトリに作成してくれる。この設定ファイルはルート直下に作成されているが、自分の場合はCI関連のファイルはまとめておきたいので.githubディレクトリに移動した。この位置でもrenovateは動作してくれる。

設定ファイルさえ用意しておけば、あとは設定通りにrenovateが以下のようなPRを作成してライブラリを更新してくれる。

renovateのPR

以下は個人開発しているTabTabTabというChrome拡張のリポジトリにおける設定ファイル。

// .github/renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "schedule": ["every weekend"],
  "labels": ["maintenance"],
  "timezone": "Asia/Tokyo",
  "automerge": false,
  "rangeStrategy": "bump",
  "dependencyDashboard": false,
  "branchConcurrentLimit": 0,
  "prHourlyLimit": 0,
  "packageRules": [
    {
      "groupName": "react",
      "matchPackageNames": ["@types/react", "@types/react-dom"],
      "matchPackagePrefixes": ["react"]
    },
    {
      "groupName": "eslint",
      "matchPackagePrefixes": ["@typescript-eslint/", "eslint"]
    },
    {
      ...略...
    },
    {
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

主な設定の方針は以下。背景や詳細は後述する。

  • ライブラリの更新作業は週末にまとめて実行する
  • 主要なライブラリはグループ分けしておく
  • メジャーアップデートや0系のアップデート以外は自動マージする
  • PRの作成数に制限は設けない

ライブラリの更新作業は週末にまとめて実行する

ライブラリの更新があるたびに通知が来ては煩わしいし、PRによっては手動でマージする必要もあるので更新作業は週末にまとめて実行されるようにしておいた。

以下のように設定しておくと、土曜日の深夜に更新用のPRが作成され始める。

{
  "schedule": ["every weekend"],
  "timezone": "Asia/Tokyo",
}

主要なライブラリはグループ分けしておく

特に追加の設定をしていないとrenovateは更新のあるライブラリごとにPRを作成するためPRの数が多くなって煩わしい。以下のように設定することで関連するライブラリをグループ化してPRを作成してくれるようになる。

{
  "packageRules": [
    {
      "groupName": "react",
      "matchPackageNames": ["@types/react", "@types/react-dom"],
      "matchPackagePrefixes": ["react"]
    }
  ]
}

もし更新後に不具合があった際に原因の切り分けがしやすいように関連ライブラリごとのグループ分けを設定したが、依存ライブラリ数が多かったり、作成されるPRの数を抑えたいときはもっと大きな範囲でグループ分けをすることも可能だ。

以下の例では、npmにおけるdependenciesとdevDependenciesでグループ分けしている。実験的にこのブログのリポジトリのrenovateの設定も以下と同じように設定しているが、今のところ特に問題はない。細かく更新内容を分けたり確認したりしなくても良いのであればこれで十分なのかもしれない。

{
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "groupName": "devDependencies"
    },
    {
      "matchDepTypes": ["dependencies"],
      "groupName": "dependencies"
    }
  ]
}

メジャーアップデートや0系のアップデート以外は自動マージする

renovateでは設定次第でPRがマージできるようにすることもできる。

最初の頃は自動マージが怖くて手動でマージしていたが、PRが作成されたときにはテストも走っているし動作確認も全てのPRをマージしてからまとめて行っているので手動でマージする必要性を感じなくなった。

ただし、ライブラリの更新がメジャーアップデートの場合は破壊的変更があり得るし、0系のライブラリの場合もいつでも破壊的変更があり得るので自動マージは怖い。そういった場合は自動マージがされないように設定しておいた。

以下の設定では、デフォルトで自動マージをオフにしておき、0系以外のライブラリのマイナーバージョンとパッチバージョンのアップデートのときのみ自動マージをオンにしている。

{
  "automerge": false,
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

PRの作成数に制限は設けない

CIの設定内容次第ではrenovateが作成するPRの数や作成方法に制限を設けたいことがあるかもしれない。例えばCIのワークフローの中で外部のAPIを叩くことがあれば、そのAPI制限を超えない運用が必要になることもあるだろう。

しかし、自分の場合はそんなことはなかったのでこの制限は不要だった。プリセットの設定であるconfig:baseでは1時間に2個のPRしか作成しないなどの制限があったため、これを設けないよう以下の設定で上書きしておいた。

{
  "branchConcurrentLimit": 0,
  "prHourlyLimit": 0,
}

おわり

renovateを使い始めて数週間が経つが、使用感は最高だ。ライブラリ更新という手間も無くなったし、常にライブラリを最新にしておくこともできる。また、renovateが作成するPR内には更新ライブラリのリリースノートの記述もあるし、更新差分へのリンクもあってとても便利だ。

タイトルに「今さら」と付けたが全然そんなことはなく、renovateは今も旬な便利ツールだった。

関連記事
最新記事
プロモーション

Copyright © 2024 OKARYO

This site uses Google Analytics.