handle squash-merge and rebase-merge PR

[tacaswell]

Trying to cherry-pick a squash-merge results in errors like:

ct 29 18:13:42 meeseeksbot app/web.1:  ---------------------------------------- 
Oct 29 18:13:42 meeseeksbot app/web.1:  == Cleaning up previsous work...  
Oct 29 18:13:42 meeseeksbot app/web.1:  == Done cleaning  
Oct 29 18:13:42 meeseeksbot app/web.1:  == Cloning current repository, this can take some time.. 
Oct 29 18:13:42 meeseeksbot app/web.1:  Cloning into 'matplotlib'... 
Oct 29 18:14:01 meeseeksbot heroku/router:  at=error code=H12 desc="Request timeout" method=POST path="/webhook" host=meeseeksbot.herokuapp.com request_id=d4ba2128-42d2-4c89-8a09-ae8477213779 fwd="192.30.252.42" dyno=web.1 connect=1ms service=30003ms status=503 bytes=0 protocol=https 
Oct 29 18:14:10 meeseeksbot heroku/router:  at=error code=H12 desc="Request timeout" method=POST path="/webhook" host=meeseeksbot.herokuapp.com request_id=0c8e8fdc-b76b-424e-9a9c-fdd42f235091 fwd="192.30.252.34" dyno=web.1 connect=1ms service=30001ms status=503 bytes=0 protocol=https 
Oct 29 18:14:14 meeseeksbot heroku/router:  at=error code=H12 desc="Request timeout" method=POST path="/webhook" host=meeseeksbot.herokuapp.com request_id=5c574610-0b16-430f-af2e-3e024888df19 fwd="192.30.252.45" dyno=web.1 connect=0ms service=30001ms status=503 bytes=0 protocol=https 
Oct 29 18:14:23 meeseeksbot app/web.1:  == Cloned.. 
Oct 29 18:14:23 meeseeksbot app/web.1:  == Fetching branch to backport on ... 
Oct 29 18:14:24 meeseeksbot app/web.1:  == Fetching Commits to backport... 
Oct 29 18:14:24 meeseeksbot app/web.1:  == All has been fetched correctly 
Oct 29 18:14:24 meeseeksbot app/web.1:  Cherry-picking 6aeeec7efde2c9dfacf88d27118c7507002af4c7 
Oct 29 18:14:24 meeseeksbot app/web.1:    stderr: 'error: Mainline was specified but commit 6aeeec7efde2c9dfacf88d27118c7507002af4c7 is not a merge. 
Oct 29 18:14:24 meeseeksbot app/web.1:  fatal: cherry-pick failed' 

Falling back to without -m 1 would work in this case, but would likely fail in interesting ways for rebase-merge.

[Carreau]

Squash merge should now be handled.

[Carreau]

(not rebase one though).

[ivirshup]

As a temporary fix, could the bot report an error in this case instead of opening a bad PR?

[Carreau]

As a temporary fix, could the bot report an error in this case instead of opening a bad PR?

Probably I would have to dive into the code and figure out how to detect that ; and post a message.
Feel free to send a PR if you have the time.

[ivirshup]

I took a quick look and couldn't figure out how to tell if a merge commit came from a rebase or squash (at least from the github rest api) (pull request docs). Either way, the merge_commit_sha exists on the target branch, and does not exist in the PR commits.

Closest alternative I thought of would be to sidestep this, do the equivalent of gh pr checkout {pr}, and cherry-pick the commits from the branch this creates. Not really sure of the ways this could fail, however.

note to self

Relevant code from this project:

https://github.com/MeeseeksBox/MeeseeksDev/blob/34fa2c7d26a0e376b2ff92fbc36c69cfe2ebf187/meeseeksdev/meeseeksbox/commands.py#L711-L729

From the GraphQL API, associatedPullRequests of commits created from rebasing will point to the correct PR. This might be an alternative solution.

Getting a rebased-commits associated PR

{
  repository(owner: "theislab", name: "scanpy") {
    pullRequest(number: 1601) {
      mergeCommit {
        # It says last: 10, but it's direct parents so there is only one result
        parents(first: 10) {
          nodes {
            message
            oid
          }
          edges {
            node {
              associatedPullRequests(first: 10) {
                nodes {
                  number
                }
              }
            }
          }
        }
      }
    }
  }
}