Cloudflare adopted Renovate when I worked there. Not sure if it was the config wasn’t good (we did try to wrangle with it a bit by customizing), but I found it to be a lot more pain that it was worth. PRs that wouldn’t build would be opened, trivial dependency updates that weren’t worth the PR time would be proposed, etc.
There’s also the security aspect of supply chain attacks of “button press” updates.
I think having reports sent to repo owners that they can review with the team on a periodic basis instead of click-through maintenance might be a better model but I also understand the desire for mindless automation of what seems like a chore.
I automated renovate PR into its own branch. Then twice a month I automatically create a PR through GitHub actions for me to review all changes at once.
I also added a cooldown period that Renovate should only add updates that are out for at least 14 days.
We also had a similar setup at Algolia, renovate push to one branch (`baseBranch` properties) and you only review once a week or month.
Created a GitHub actions to create the base branch with a cron:
https://github.com/bodinsamuel/renovate-automatic-branch
So you have nothing to do except a big review once in a while.
I have a branch lock on dev and main so that you can only merge through PR. So I created a branch from dev called "renovate_updates". In the renovate config I set the baseBranch config parameter to this branch. I also enabled automerge and minimumReleaseAge.
On GitHub I created two actions:
1. It gets triggered on the 14th and the 1st of a month and creates a PR from renovate_updates to dev and assigns it to me. I use an action to identify as a github app that I have given the rights to in the repo. Within the github action you can use gh cli.
2. Everytime there is a merge to the dev branch the action gets trigerred and does a rebase of dev of that "renovate_updates" branch.
The nice thing about this is that Renovate creates an Issue in your repo and you can still force versions if you need them earlier.
What strategy do you use for conflicts during the rebase of renovate_updates? (which most of the time would occur because you eagerly updated something on dev)?
Renovate is still rough. My team has some repos that Renovate inexplicably doesn't vendor Go dependencies on, even though it works just fine with other repos with the same config.
Isn't that exactly what you want from the dependency update system? If some dependency bump breaks the build, why wouldn't you want to know about it? And if not, how would this system know that the PR will fail before opening it? I'm not sure I get what behaviour you expect.
There’s also the security aspect of supply chain attacks of “button press” updates.
I think having reports sent to repo owners that they can review with the team on a periodic basis instead of click-through maintenance might be a better model but I also understand the desire for mindless automation of what seems like a chore.