This sounds awesome can you share any details on how you got this to work?

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)?

That’s a good point. My repo doesn’t change that often. But for me the source of truth is always dev.

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.