I also added a cooldown period that Renovate should only add updates that are out for at least 14 days.
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.
So you have nothing to do except a big review once in a while.
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.