💡 How to rebase a pull request?

[gr2m]

This question came from @davidguttman via Twitter: https://mobile.twitter.com/davidguttman/status/1386374058321743874

I've seen that question came up several times. I know there are existing GitHub Apps and GitHub Actions out there that can rebase open pull requests, but I think the topic comes up often enough to dive into it and explore how it works.

In order to turn this into a show, I think we should

• research the existing ready-to-use apps, actions, and other tooling for rebasing a PR on GitHub
• Come up with a specific use case / scope that we could accomplish in a 30 minute show

@davidguttman what would be a good use case for yourself? We could set the goal to create an app that folks can install, an action that folks can setup, or a script that folks can use in their custom GitHub Actions workflow. Should it rebase all open pull requests after a push to the default branch, or only a subset? What should it do if it failed to do a rebase?

[davidguttman]

For many of the teams I oversee, PRs move from in progress, to needs review, to ready to deploy. Often, the person responsible for merging/deploying the PR in RTD can’t do it from the UI because something else was merged to main/master after this PR had been reviewed and approved. The person responsible for the deploy can “fix” this by checking out the PR branch locally, rebasing main/master and force pushing. After that, there are no conflicts and the UI can be used to merge.

I’m not sure the best form for this automation to take, but I had imagined it could work like dependabot via a comment trigger (@dependabot rebase). Either triggered by the deploy person or handled more automatically would work great, but I’m not sure if there would be unintentional side effects caused by more automatic means.

If a rebase can’t happen cleanly in the comment trigger approach, I figure a reply saying so and indicating manual intervention is required would work.

[gr2m]

That's great, thank you David!

the person responsible for merging/deploying the PR in RTD

What's RTD? Read the docs?

How about we split this into two parts:

1. Create a configurable command parser action which would work similar to probot's commands. For our use case the command could simply be /rebase. The command parser parses this into something like

   {
     "command": "rebase",
     "author": { /* full user object */ },
     "is_collaborator": true,
     "is_owner": true
   }

   and writes it into the action step output.

2. Write the action which does the actual rebase, but only run it based on the output of the command parser (using if). The action would also add a comment in case of an error with an explanation of what went wrong.

That way we you could use the manual trigger with a /rebase comment, but you could later also automate it entirely. What do you think?

[davidguttman]

Yeah this sounds perfect! probot looks awesome

RTD is "ready to deploy" -- wrote it out before using the acronym but should have been more clear.

Sorry to have missed this. Github notifications are something else I need help with 😅

[gr2m]

Sorry to have missed this. Github notifications are something else I need help with 😅

haha no worries!

There is some prior art for slash commands:

• https://github.com/marketplace/actions/slash-commands
• https://github.com/marketplace/actions/slash-command-dispatch

I like slash-command-dispatch quite a bit! I wish it was an app, that would make it much snappier, github actions have quite a delay as they need to be spawned up first, a GitHub app that you just install in your repository would respond immediately 🤔

Anyway, would you like to colab on this tomorrow 1pm Pacific Time live on https://www.twitch.tv/gregorcodes?

[davidguttman]

Happy to collab! I'm available 1:30 - 4pm today (Thursday 5/13) and most of the day tomorrow (Friday 5/14).

[gr2m]

Sounds good! I'll start my stream at 1pm and do some preliminary work, you can join in at 1.30pm and we can see how far we can get it today within an hour max

[gr2m]

done at #13