Branch-based automerge is challenging with a busy main branch

[nordbergm]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitHub / renovate-ce 7.5.0

Please tell us more about your question or problem

We've configured Renovate for branch-based automerge with "automergeType": "branch", "automerge": true and "rebaseWhen": "auto" which in itself is working as expected.

However, because our repository is a large monorepo with very frequent commits to the main branch, coupled with github checks taking a while to complete, Renovate ends up in an infinite loop of trying to keep these branches up to date with main. As a result, Renovate rarely gets a chance to merge branches due to this.

We briefly tried to use "rebaseWhen": "conflicted" in an attempt to allow stale branches, however, this triggers this code in Renovate and forces a PR instead.

What is the recommended way to configure Renovate in this scenario to avoid the infinite rebase loop?

Merging stale branches is ok with us in this scenario.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[rarkins]

In theory, Renovate's approach that branch automerging updates must be up-to-date with the git base branch is an "opinionated" setting which could be made configurable. However how would you anticipate the git to look like when merging "stale" (behind) branches? e.g. a git merge commit (non-ff), or a git rebase commit?

[nordbergm]

Git merge commit (non-ff) would be the preferred option, but I can definitely see people having different opinions on this. Renovate's opinionated approach is a sensible default (it is safer), but having the option to configure the automerge behaviour would be great.

[rarkins]

We could reuse automergeStrategy for this, as it defaults to auto. i.e. automergeType=branch and automergeStrategy=auto means fast-forward as done today. Users could now configure merge-commit or rebase, in which case the branch automerge should use that approach.

The next question is what to do about rebaseWhen. In this discussion the goal would be that if rebaseWhen=auto and automergeStrategy=merge-commit then Renovate doesn't keep rebasing to keep the branch up-to-date. But I think the same should apply for PRs.

@viceice @secustor wdyt about changing rebaseWhen=auto behavior so that if automergeStrategy is fast-forward or rebase then we no now map rebaseWhen=auto to rebaseWhen=conflicted instead of rebaseWhen=behind-base-branch?

[secustor]

That could theoretically result in broken lockfiles as the install commands are not run in a FF commit.
So I'm for keeping the default value as is.

[rarkins]

If automergeType=branch, rebaseWhen=auto, and automergeStrategy=auto, then we keep like today (rebasing to keep up with base branch). If the user configures automergeType=branch, leaves rebaseWhen=auto, but configures automergeStrategy=fast-forward, then I think we should map that to rebaseWhen=conflicted. The user's intent is clear here, and it can't be an accident that they configure automergeStrategy=fast-forward