Configure RenovateBot #43
Conversation
|
Turns out the thing is rather chatty... and rather bratty as well. This should discipline it a bit. |
Zsar
force-pushed
the
configure-renovate-bot
branch
2 times, most recently
from
91ac018 to
e224715
Compare
? will automerge less-than-minor changes ? will create rollback PRs if updated versions have been pulled afterwards (Note: should not actually happen, because stabilityDays is bigger than time limit for pulling from npm registry) ? will group updates together instead of creating one PR for each dependency ? will only check updates on sundays and only create PRs on saturdays (that is, after one work week has passed) ? will only create PRs for major versions if authorised to on dependency dashboard ? will update only lockfile, if in-range updates are available ? will wait for five days before considering a change stable
Zsar
force-pushed
the
configure-renovate-bot
branch
from
e224715 to
029e41a
Compare
| ], | ||
| "assignees": ["Zsar"], | ||
| "automergeStrategy": "merge-commit", | ||
| "configMigration": true, |
There was a problem hiding this comment.
The renovate.json itself is considered non-stable by RenovateBot maintainers. This setting should at least alert us that our configuration no longer works as expected.
| "packageRules": [ | ||
| { | ||
| "groupName": "trivial", | ||
| "matchUpdateTypes": ["bump", "digest", "lockFileMaintenance", "patch", "pin", "pinDigest", "rollback"], |
There was a problem hiding this comment.
I had a hard time finding definitions for most of these types, so I am not entirely sure this is the correct set.
Alas.
| "rollbackPrs": true, | ||
| "schedule": ["on sunday"], | ||
| "stabilityDays": 6, | ||
| "packageRules": [ |
There was a problem hiding this comment.
This should provide us with three different upgrade paths:
- Everything not-even-minor will be automatically merged, in the hopes that everyone... well, else, uses proper SemVer. This should cut down a lot on Dependabot alerts.
- Everything minor will be automatically created but requires human review. I hope this will be manageable, because we only check once per week now.
- Everything major will not even be attempted until we order it on the Dependency Dashboard issue. Some libraries we simply might not want to update (but rather, eventually, replace or outright drop).
| "automergeStrategy": "merge-commit", | ||
| "automergeSchedule": "on saturday", | ||
| "configMigration": true, | ||
| "rangeStrategy": "update-lockfile", |
There was a problem hiding this comment.
This setting should cause PRs when transitive dependencies update within allowed ranges. - I've had several Dependabot alerts that really have been fixed without any direct dependency change, so I find this option appealing.
| "configMigration": true, | ||
| "rangeStrategy": "update-lockfile", | ||
| "reviewers": ["Zsar"], | ||
| "rollbackPrs": true, |
There was a problem hiding this comment.
If someone un-publishes their npm package, they probably have a very good reason to.
Note that as-is this setting will probably do nothing, because you can only do unpublish within 72 hours of publishing and I have set stabilityDays to higher than this. If we (or npm) later diverge from those settings, this option will step in if an update was "too hot" after all.
|
Rightee-o, going to try this out! Really interested in what will happen to its currently open PRs... |
Configure RenovateBot
? will automerge less-than-minor changes
? will create rollback PRs if updated versions have been pulled afterwards (Note: should not actually happen, because stabilityDays is bigger than time limit for pulling from npm registry)
? will group updates together instead of creating one PR for each dependency
? will only check updates on sundays
? will only create PRs for major versions if authorised to on dependency dashboard
? will update only lockfile, if in-range updates are available
? will wait for six days before considering a change stable