Config-help: How can I configure renovatebot to stop rebasing PRs?

[spalger]

Which Renovate are you using? CLI, App, or Pro

App

Which platform are you using? GitHub, GitLab, Bitbucket Azure DevOps

Github

Have you checked the logs? Don't forget to include them if relevant

Yes, but I don't understand what might be relevant https://renovatebot.com/dashboard#github/elastic/kibana

What is your question?

How can I configure renovatebot to stop rebasing PRs so quickly. This behavior is creating a lot of noise in our CI and a bit of thrashing which our Jenkins instance isn't handling very well and I'd really like to be responsible for triggering rebases manually or merging the base branch when necessary.

[spalger]

From https://github.com/elastic/kibana/pull/37406

[rarkins]

@spalger I'll get back to you with a config suggestion in a short while. I want to take a look at your config first

[rarkins]

I'm not sure exactly yet of what's going on. Let me know at ay time if you want me to pause the bot for this repo in the meantime.

Anyway, Renovate usually rebases under these circumstances:

• If the branch is conflicted with master (usually happens if you merge one Renovate PR with package.json and there's another PR editing adjacent deps)
• If your repository has a branch protection setting for master that says "PRs must always be up to date"
• If you manually configure rebaseStalePrs=true in config

I think I see you've tried to set rebaseStalePrs to false in your config now, although I need to double check timestamps to see if all the problems were before or after this. If the branches were conflicted then rebasing will happen regardless of the rebase stale setting

[rarkins]

If I look at the logs for the renovate/babel branch, which had some rebasing done, I see this message around 05:17 UTC: Need to update package file so will rebase first. There's a similar message for grunt. This implies that the existing branch didn't have a correct version of one of the dependencies it was updating.

[spalger]

Okay, it must be because of conflicts, I've had the rebaseStalePrs=false setting on for a while now trying to curb this problem. Do you think there might be something else going on which is causing the switch between "pin dependencies" pr titles and "update {group name}" pr titles? I wonder if that might have something to do with the vigorous rebasing.

[rarkins]

Normally, all "Pin" PRs should come under a single big PR called "Pin Dependencies" and it has branch name renovate/pin-dependencies. Something in your config is overriding that, so that was something I was intending to look at next

[rarkins]

Answer: the groupSlug field is what overrides the Pin Dependencies PR's default branch name. I could try to "fortify" the default settings to make it harder to accidentally override the renovate/pin-dependencies name, although it takes a little while to push that live to the app (tests passing, releasing etc).

[spalger]

I'm trying to avoid a massive flood of PRs because we have soooo many packages that need updating, and was trying to use packageRules to only update small groups at a time, do you think I should take another approach? Maybe I should wait until everything is updated to start pinning things?

[spalger]

Maybe I should start with rangeStrategy: replace

[rarkins]

Quick fix: set masterIssueApproval: true. That way no PRs get raised (from now on) without you checking a box in the master issue

[rarkins]

Normally I recommend pinning at the start though, but with a single Pin PR of course. That way it's not normally a big deal. I'm working to reproduce your config/pin setup right now to verify that I can force all PRs into one again

[spalger]

Ah, masterIssueApproval is awesome, then I can get rid of the overrides based on packageRules? I can rely on the master issue to control which PRs will be opened.

[rarkins]

Yes, with that approval then not a single PR will be created unless you tick the checkbox next to it. Also, it means you get a kind of "preview" of the groupings and if something doesn't look right then you could update your renovate config then see the updated preview in the master issue.

[rarkins]

You might still want to have plenty of those package rules remaining though, e.g. grouping grunt, babel, etc.

[rarkins]

Closing this, as I think we have explained and solved the problem. FYI I pushed a small fix that should force group "Pin Dependencies" PRs together by not allowing override of the groupSlug field.

[spalger]

Thanks!

[spalger]

I agree that the problem is under control, but I do think it would be awesome if there was a way to configure opting-in rebasing for PRs, in case you're looking for even more to make configurable!

[rarkins]

Do you mean opt-in rebasing of conflicted PRs? I'm pretty sure that the existing option does work fine if it's simply out of date ("stale"), so the only part missing is whether to stop Renovate rebasing conflicted PRs.

[spalger]

Yeah, that's what I'm thinking, the ability to only rebase conflicted PRs when the user requests it. It might not be worth the work implementing it, but I would have found that useful when it felt like my PRs were constantly being rebased without conflicts.