Renovate メモ
Renovate のドキュメントは充実しているものの、ドキュメントを読んだだけではよくわからなかったり、
勘違いしてしまうこともあると思います。
Preset Config config:base
では様々な Config が入れ子になって読み込まれているため、
意図していない設定がされていることもあります。
なので、 Renovate に関して気づいたことを、メモしていきたいと思います。
config:base
で prHourlyLimit が 2 に設定されている
- https://docs.renovatebot.com/presets-config/#configbase
- https://docs.renovatebot.com/configuration-options/#prhourlylimit
Renovate で作成される PR の量を増やしたい場合、 prHourlyLimit を増やす必要があります。
config:base
使わないのも一つの手?
config:base
では様々な設定がされており、悪く言うと blackbox です。
config:base
の内容をきちんと理解した上で使っている人は少数でしょう。
であれば config:base
を使うのをやめ、必要になったら設定を追加していくというの一つの手だと思います。
とはいえ、 config:base
では公式推奨の設定がされているといっても過言ではないと思うので、
使うのが無難かなという気もします。
grouping 使うべき?
- https://docs.renovatebot.com/configuration-options/#group
- https://docs.renovatebot.com/noise-reduction/#package-grouping
grouping は複数の package を一つの PR で update する機能です。
複数の package に依存関係があり、同時に update する必要がある場合などに便利です。
また、 Renovate の PR の数を減らす効果も期待できます。
一方で、一つの PR に含まれる変更が大きくなるという側面もあります。
個人的には grouping は言わば advanced な feature だと思っています。
そして一般論として、 advanced な feature は、本当に必要になったらそのときに取り入れれば良いと思っています。よく理解していないのであれば使う必要はないはずです。
使うのであれば、使う意図がコードから伝わるようになっているのが望ましいと思います(必要であればコードコメントが欲しいです)。
なぜこんなことを書いているというと、コピペで groupName を設定しているようなコードを見かけたからです。
Renovate のコードの entrypoint
yarn start
の entrypoint をチェックする。
lib/renovate.ts
automerge: true で reviewer が assign されないか確認する
By default, Renovate will not assign reviewers and assignees to an automerge-enabled PR unless it fails status checks.
By configuring this setting to true, Renovate will instead always assign reviewers and assignees for automerging PRs at time of creation.
automerge: true で reviewer が assign されないか確認する
- https://github.com/suzuki-shunsuke/test-renovate/pull/110
- https://github.com/suzuki-shunsuke/test-renovate/tree/6dad412b36e629c0b85e9c896997678de6d3b654
- https://github.com/suzuki-shunsuke/test-renovate/blob/6dad412b36e629c0b85e9c896997678de6d3b654/Dockerfile
- https://github.com/suzuki-shunsuke/test-renovate/blob/6dad412b36e629c0b85e9c896997678de6d3b654/renovate.json
reviewers を設定しているが、 assign はされなかった。
CI を失敗させてみる
CI が失敗しているが、 assign はされない
automerge を false にして assign されるか確認する
PR 作り直したら assign された
PR 作成時しか assign されないのかな
確かに unassign したものが再び assign されたら不便なので作成時だけなのかもしれない
結論
- reviewers の assign は PR 作成時のみ行われる
- automerge: true の場合、 CI の結果に関係なく、 reviewers は assign されない
- assign したい場合は
assignAutomerge
を true にする
- assign したい場合は
Renovate の文字列のフォーマットは? glob? 正規表現?
幾つかの設定で文字列を使うが、そのフォーマットがドキュメントに書いていない。
調べてまとめる
幾つかあったと思ったが、これ以外はドキュメントに書いて有りそう
major
major update の場合のみ適用する。いままで packageRules に書いてたが、 global に書けるのは便利。
設定できるフィールドなどのドキュメントがない気がする
kustomize を update する
- name: kubernetes-sigs/kustomize@kustomize/v4.0.0
"packageRules": [
{
"matchPackageNames": ["kubernetes-sigs/kustomize"],
"matchManagers": ["regex"],
"extractVersion": "^kustomize/(?<version>.*)$"
}
]
{
"depName": "kubernetes-sigs/kustomize",
"currentValue": "kustomize/v4.0.0",
"datasource": "github-releases",
"replaceString": " name: kubernetes-sigs/kustomize@kustomize/v4.0.0",
"depIndex": 1,
"updates": [],
"warnings": [],
"versioning": "semver",
"skipReason": "invalid-value"
}
"packageRules": [
{
"matchPackageNames": ["kubernetes-sigs/kustomize"],
"matchManagers": ["regex"],
"extractVersion": "^kustomize/(?<version>.*)$"
}
],
"regexManagers": [
{
"fileMatch": ["\\.?aqua\\.ya?ml"],
"matchStrings": [
" +['\"]?name['\"]? *: +['\"]?kubernetes-sigs/kustomize@kustomize/(?<currentValue>[^'\" \\n]+)['\"]?"
],
"datasourceTemplate": "github-releases",
"depNameTemplate": "kubernetes-sigs/kustomize"
}
]
"regexManagers": [
{
"fileMatch": ["\\.?aqua\\.ya?ml"],
"matchStrings": [
" +['\"]?name['\"]? *: +['\"]?kubernetes-sigs/kustomize@kustomize/(?<currentValue>[^'\" \\n]+)['\"]?"
],
"extractVersionTemplate": "^kustomize/(?<version>.*)$",
"datasourceTemplate": "github-releases",
"depNameTemplate": "kubernetes-sigs/kustomize"
}
]
tflint の plugin を update する preset
Renovate が GitHub Actions x.y.z-0 を x.y.z に update してくれない原因と修正方法
name: dummy
on:
pull_request:
branches: [dummy]
push:
branches: [dummy]
jobs:
conftest:
runs-on: ubuntu-latest
steps:
- uses: suzuki-shunsuke/tfaction/setup@v0.5.12-0 # これを v0.5.12 に update したい
自分は prerelease version として x.y.z-0 とか x.y.z-1 とかをリリースしたあとに
x.y.z をリリースすることがある。その場合 x.y.z-0 を x.y.z に update してほしいが update されない。
Renovate のログを見る
{
"depName": "suzuki-shunsuke/tfaction",
"commitMessageTopic": "{{{depName}}} action",
"datasource": "github-tags",
"versioning": "docker",
"depType": "action",
"replaceString": "suzuki-shunsuke/tfaction/setup@v0.5.12-0",
"autoReplaceStringTemplate": "{{depName}}/setup@{{#if newDigest}}{{newDigest}}{{#if newValue}} # tag={{newValue}}{{/if}}{{/if}}{{#unless newDigest}}{{newValue}}{{/unless}}",
"currentValue": "v0.5.12-0",
"depIndex": 0,
"updates": [],
"warnings": [],
"sourceUrl": "https://github.com/suzuki-shunsuke/tfaction",
"currentVersion": "v0.5.12",
"fixedVersion": "v0.5.12-0"
}
]
}
特にエラーは吐いていない。
Renovate の version 文字列の扱いを確認する。
The "versioning" is different for each package manager
github-actions manager の default の versioning を調べる
versioning については書いてない。
Renovate の上記のログを見たら "versioning": "docker",
だった
12.15.0-alpine which is not compatible with 12.15.0 or 12.15.0-stretch. This means users only want/expect upgrades to 12.16.0-alpine and not 12.16.0 or 12.16.0-stretch.
なるほど。 docker だから x.y.z と x.y.z-0 には互換性がないという扱いになって update されないのか
semver にすればいいのかな?
npm もあるが、今回は semver で良さそう。 range サポートとかいらない
npm versioning is the most well known/widely-used implementation of Semantic Versioning 2.0.
It's important to understand that "npm" versioning scheme is not the same as "semver" versioning.
SemVer's spec does not define ranges at all - so all range/constraint syntax in npm is npm-specific and not part of the spec.
出来た。
github-actions manager の default の versioning が docker なのってあまり適切でもないような。
default semver でいいんじゃないだろうか。
depName と packageName の違い
private repository のツールの update
github-tags や github-releases datasource の場合、 private repository に Renovate の GitHub App をインストールしておけば良い。
他の datasource では、その datasource を参照するための credential が必要になるだろう。
github-tags や github-releases datasource の場合でも、 private repository に GitHub App をインストールしない場合、ドキュメントに書かれているようなやり方で credential を渡す必要があるのだと思われる。
確かにツールを管理しているリポジトリでは Renovate 使いたくないって場合はあるだろう。
その場合でも renovate.json を作らなければいいし、あるいは renovate.json で enabled: false
にすればいい話ではある。
aqua の場合は基本は github-tags や github-releases datasource なので Renovate さえインストールすれば難しいことはない。
ただ、 go_install
package だと private repo に対して go install
することになるので、動かないかもしれない。要確認。ただこれは aqua install
の話であって Renovate の話ではない。
private repo を2つ作る
- https://github.com/suzuki-shunsuke/test-renovate-private-tool-update
- https://github.com/suzuki-shunsuke/test-private-cli
test-renovate-private-tool-update で test-private-cli を利用する
---
# aqua - Declarative CLI Version Manager
# https://aquaproj.github.io/
registries:
- type: local
name: local
path: registry.yaml
packages:
- name: suzuki-shunsuke/test-private-cli@v0.1.0
registry: local
{
"extends": [
"config:base",
"github>aquaproj/aqua-renovate-config#1.2.4"
]
}
update された。
改竄されたツールの実行を防ぐために stabilitydays を設定する
Renovate の Pull Request を自動マージすることの懸念の一つとして、ツールが改竄されていても気づかずに update し、実行してしまう可能性があるという点があります(もちろん、人間がレビューしても気づかない可能性は十分あるので、これを自動マージの懸念というのは語弊があるかもしれません)。
これは例えば攻撃者がツールのリポジトリの write 権限を奪って悪意のあるコードを混入して新しいバージョンをリリースしてユーザーにインストール・実行させるといった攻撃が考えられます。
これを完全に防ぐことは難しいですが、 Renovate の stabilitydays を設定して update を遅らせることで、自分たちがツールを update する前に事前に問題が検出・解決される可能性を高めることが出来ます。
stabilitydays としては 1, 2 程度で良いのではないでしょうか。
長ければ長いほど可能性は上がりますが、あまり伸ばしても意味はないし update が遅くなるだけですし、攻撃によるインパクトが大きいようなツールの改竄であれば恐らく直ぐ誰かが気づくでしょう。
数日で誰も気づかないようなものであれば、たとえ自動マージしないで人間がレビューしたところで気づくことは出来ないでしょうし。
stabilitydays だけでなく schedule でも同様の効果は期待できる場合もありますが、 schedule の場合タイミングが悪ければ新しいバージョンが出てすぐ update される可能性があるので、 stabilitydays のほうがより確実でしょう。
ただし、 stabilitydays が効かないような datasource もあるようです。
Some datasources do not provide a release timestamp (in which case this feature is not compatible), and other datasources may provide a release timestamp but it's not supported by Renovate (in which case a feature request needs to be implemented).
v0 では automerge を disable にする
Default Preset があるかと思ったらなさそう?
多分 matchCurrentVersion を使えばいける
"packageRules": [
{
"automerge": false,
"matchCurrentVersion": "/^0\\./"
}
]
tfaction では v0 の間 minor で breaking change, patch は non breaking change という運用にしているので
matchUpdateTypes を追加すると良い。
"packageRules": [
{
"automerge": false,
"matchUpdateTypes": ["minor", "major"],
"matchPackageNames": ["suzuki-shunsuke/tfaction"],
"matchCurrentVersion": "/^0\\./"
}
]
stabilityDays がリネームされていた