Renovate unnecessarily rebases PRs

[gkalpak]

What Renovate type, platform and version are you using?

We are using the Renovate App on GitHub.

Describe the bug

On the angular/ngcc-validation repo, in the last few days (at least), we have noticed the following behavior:

Once Renovate merges one of its PRs, it will rebase all its open PRs, although there should be no merge conflicts created by the recent merge.

For example, you can see that once angular/ngcc-validation#2643 was just merged, Renovate rebased angular/ngcc-validation#2645 (which had already passed CI). By looking at the changed files, it is clear that there should be no merge conflicts between the two PRs.

This behavior is highly undesirable, since (in addition to taking a lot longer to merge PRs) it causes CI to run much more than necessary (increasing CI costs and consuming CI resources).
Any insight on what might be going on or how to fix it would be appreciated 🙏

Relevant debug logs

I am not sure what part of the logs is relevant. You can find the whole file here.

There were a couple of places that said that the branch was stale and needed rebasing and the lockfile needed updating, but not sure what to make of that:

DEBUG: Branch is stale and needs rebasing(branch="renovate/azure-msal-browser-2.x")
DEBUG: Using reuseExistingBranch: false(branch="renovate/azure-msal-browser-2.x")

DEBUG: yarn.lock needs updating(branch="renovate/azure-msal-angular-2.x")
DEBUG: updateYarnOffline resolvedPaths(branch="renovate/azure-msal-angular-2.x")
{
  "resolvedPaths": []
}
DEBUG: Updated 1 lock files(branch="renovate/azure-msal-angular-2.x")
{
  "updatedArtifacts": [
    "yarn.lock"
  ]
}

Have you created a minimal reproduction repository?

• This is a really small bug, it does not need a reproduction (think small typo)
• I have provided a minimal reproduction repository
• I don't have time for that, but it happens in a public repository I have linked to
• I don't have time for that, and cannot share my private repository
• The nature of this bug means it's impossible to reproduce publicly

Additional context

N/A

[viceice]

This is by design, renovate will ever only automerge up to date pr, so it needs to rebase. see rebaseWhen to change behavior, but this will stop automerge i think.

Also it will only automerge when renovate is latest git author (can be changed when #8893 is done).

[toxsick]

Hey guys,

good I found this. If this is new behaviour the docs on this are a little misleading I think:

https://docs.renovatebot.com/updating-rebasing/#rebasing-out-of-date-branches

I would think that renovate will not by default rebase every merge request, when something else is committed to the master branch. In my case I definitely have to disable this setting and use the "rebaseWhen": "conflicted", because I have multiple CI Pipelines with e2e tests end everything, which run up to 5 times before they get finally merged, because they play ping pong with other merge requests.

But now I know about the new default I'm happy :)

Thanks a lot for renovate guys, saves me hours every week!

[HonkingGoose]

You might want to follow issue #8988 to be notified of changes to the docs. 😉

[anantakrishna]

Interestingly, #8988 mentions “update text in Renovate PR body” in the title, but the “Update Renovate PR body text” checkbox not ticked in the description of the issue. Perhaps because of this @rarkins have just updated the docs, as questioned by @HonkingGoose in #8988 (comment).

Also, #9031 effectively only adds a warning to the docs that,

rebaseWhen=conflicted is not recommended if you have enabled Renovate automerge

It does not add anything regarding the fact that “rebaseWhen=auto will rebase all automerge pr's / branches by default.”

However, https://docs.renovatebot.com/updating-rebasing/ describes the behavior correctly, sadly I could not find that page and spent too much time trying to figure out why Renovate is rebasing my branches.

I think that changing the PR text is absolutely necessary.

[anantakrishna]

Then we can respect the rebaseWhen=conflicted instead of converting it to rebaseWhen=behind-base-branch

@rarkins is this a plan or reality now?

[rarkins]

It's done, but it's still a bad idea which will block automerging in most cases.