Use rebase instead of merge method to update PRs when using queue action

[mzwaen]

Hi! we are new to mergify and would like to use this tool to solve this specific situation:

We would like PRs to be automatically merged to the develop branch (our default branch) when certain conditions are met, in particular, when several CI checks (including GitHub actions) passed.
PRs that are out of date should be rebased to develop, CI tests should then be retriggered and the PRs should only be merged if the CI checks were successful.

I saw that the strict_method=rebase option should be able to achieve this, and I was going to use this configuration that seems to work well for the use case described above:

   actions:
      merge:
        strict: smart
        strict_method: rebase
        method: merge

but the documentation says that this option is now depreciated: https://docs.mergify.io/actions/merge/

It suggests replacing the merge action with the queue action and I therefore tried this configuration:

    actions:
      queue:
        name: default
        method: merge

However, from what I can see, using the queue action, there is no option to update the PRs using the rebase method rather than the merge method. With the merge method, the new changes in develop are merged into the PR branch and mergify adds a merge commit to it, which is not what we want.

Does a rebase method exist for the update of PRs when using the queue action? I know that the rebase method has some drawbacks:
https://docs.mergify.io/actions/merge/#strict-rebase
but we would be ready to live with them.

If the option to use the rebase method is not available for the queue action, are there risks in continuing using the depreciated Strict merge option? According to the documentation, it should be able to prevent merging broken pull requests as it should retrigger all CI tests after the PR has been updated. Could you confirm this is the case and we can keep using this depreciated method (so the first configuration)?

Thank you very much in advance!

[jd]

Hi @mzwaen,

There's no rebase update method available for the queue action, mostly because when using speculative_checks, only merge operations are supported to test the code speculatively. Therefore we did not (re)implement the rebase update method to keep things simple.

I'm surprised that you're using the merge method if you're using rebase to update the PR. In general, we've seen people more interested into having a linear history using rebase as the merge method.

What's the underlying reading for wanting rebase as the update strategy? What'd be wrong for you with a regular merge?

[mzwaen]

This is great! Thanks a lot @jd for your explanations and for planning to add the feature to the queue action, this will be very helpful for us!

[jd]

@mzwaen We've added rebase as a method to the queue action.

[AraHaan]

@jd Can it be possible to have the update method of the queue to be both: rebase+squash (mergify will only use the squash part of it if pr's commits is > 1) while wanting to merge the pr with only rebase?

Currently my configuration uses:

      merge:
        strict: smart+fasttrack
        strict_method: rebase
        method: squash

On one of the rules to some of the repositories that I maintain.

[jd]

I'm not sure what the point of squashing after a rebase would be? You'd lost history while trying to update a PR, that sounds like a bad idea.
Could you elaborate?

[AraHaan]

Sure, basically on my PR's I want them to be rebase merged to a single commit after it uses rebase to update followed by a squash if the branches commits are 2 ahead of the base branch to make it 1 ahead of it and then it pushes it to the PR branch where then the CI reruns and if it passes it gets merged.

Alternatively it could be made to squash first then rebase on top of the base branch when it updates the PR. Either way works for me.