Renovate: Rebase on command

[rarkins]

This issue discusses a new feature to allow users to "manually ask" Renovate to rebase one of its branches.

Background:

• If users have made edits to a branch, Renovate won't touch it anymore, Otherwise:
• Renovate will always rebase/recreate a PR if it has conflicts
• Renovate will always rebase/recreate a PR if it falls behind master and if rebaseStalePrs=true
• Renovate will always rebase/recreate a PR if it falls behind master and it's a GitHub repository with "PRs must be kept up-to-date with the base branch" branch protection enabled (Renovate only, not Forking Renovate app as it doesn't have the permissions)

This means that if neither of the last two is true then Renovate PRs may become "stale" behind master and a user of them may wish to have them rebased.

An example of this was here by @mprobst: https://github.com/angular/tsickle/pull/709#issuecomment-358661211

The logic would be:

• If a PR contains the right "command" from a user, and that user has repository write access
• If that command was made after the last commit in the repository

...then rebase it.

GitHub App's webhooks can hopefully make this near real-time, although it should also work ok for anyone running on a cron'd cycle too.

The final question is, which "command" to use? It makes some sense to support "@renovate-bot rebase", however (a) we don't need to have our username in order to get webhooks, and (b) it's not very portable for non-app cases. Uber's merge bot (https://github.com/uber-workflow/probot-app-merge-pr) seems to default to "!merge", so then maybe "!rebase" would be an option.

Along similar lines, maybe we should also support a similar command that allows someone to "abandon" a PR and have it restarted from scratch, e.g. if they make a mistake when editing it. If someone has done work to edit a branch then we can't "literally" rebase it and must instead wipe/recreate it. It would be terrible if the work was important and they misunderstood the meaning of our "rebase" and lost their work. So instead I suggest it should be a different command, such as "!restart".

FYI the @renovate github username belongs to someone else, and I have been unable to reach him/her to ask if they would donate it to the project to reduce confusion. In fact they maybe don't even know that this app of the same name exists.

[rarkins]

@KevinGrandon do you have any tips to share, based on your experience writing interactive bots?

[KevinGrandon]

Thanks for looping me in. I'm not entirely sure that renovateapp needs to handle this besides additional messaging, but if it's a value-add for users I suppose it could be useful.

I like the idea of something generic like !rebase, though ideally you would be able to have a configuration to change the value it looks for? Potentially resulting in two new configuration values:

rebaseCommentEnabled = true
rebaseComment = '!rebase'

[rarkins]

I suppose the commands could be templated too, or at least the prefix. e.g. default prefix is !, can be customised to @mybot, etc.

[ticky]

I’ve just encountered a situation where I want this myself, wherein I had a series of failures due to an outdated dependency, which has since been merged into master, but because it doesn’t cause conflicts with the other PRs Renovate created, it won’t rebase them so CI runs with the fixed dependency.

Perhaps “PR falls behind master and one or more of its checks failed” would be a useful addition to the set of conditions?

[rarkins]

Copy/pasting from @danlunde in #2521:

What would you like Renovate to be able to do?
There's been a number of occasions where a renovate branch will fail one or more of our PR checks and tests due to an incompatible dependence on a different package. Often the problem will be resolved after merging in a separate renovate branch, however that branch doesn't create a merge conflict with the original renovate branch, the original won't get rebased on master and the checks will continue to fail.

Describe the solution you'd like
A method to opt-in a renovate PR to rebase itself without having to rebaseStalePrs on for every renovate PR. My suggestion would be to add a custom rebase or similar label onto the PR, then the next time renovate runs it will rebase the branch and remove the label.

Describe alternatives you've considered
According to https://renovatebot.com/docs/updating-rebasing/, I could set rebaseStalePrs to true, but that will generate a lot of unnecessary churn with our CI and this problem doesn't occur often enough to go that route. That's also the reason we don't have "Require branches to be up to date before merging" turned on. Maybe there's already a way to perform this function in a one-off manner, but I couldn't find it.

[rarkins]

Using labels will not be for everyone, but it could be a good first step because if we see the label then we know it must have been set by a collaborator and not by some random person.

Previously fetching labels for each PR would have required extra requests every time "just in case" but now with GraphQL we should be able to do this without additional cost.

[danlunde]

Thanks for pulling my request into this ticket! I'm in favor of any method, be it PR label, comment, or anything else to trigger a rebase. Been using renovate for a couple weeks on two different projects and it is making it waaaaaay easier to manage our dependencies. Thank you!

[rarkins]

@danlunde I like the label idea and should have it ready today!

[renovate-bot]

:tada: This issue has been resolved in version 13.66.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[rarkins]

This is now implemented and live in the app. Note however that we don't yet have webhook detection for label additions to PRs so it won't rebase immediately - it will happen on the next time Renovate runs (once per hour unless there is some other event that triggers it to run).

Although adding a label is not the perfect solution in every case, I have closed this issue for now and will discuss/implement additional approaches in new issues in future.

[danlunde]

just tried it out on a couple stale PRs and it worked beautifully! thanks so much for making this happen, and astonishingly quickly too!

[rtsao]

Although adding a label is not the perfect solution in every case, I have closed this issue for now and will discuss/implement additional approaches in new issues in future.

The new GitHub checks API might be a good alternative to labels.

[rarkins]

@rtsao thanks, I’ll look into it