Use different merge methods for different labels

[Tapchicoma]

Hi, maybe I don't fully understand rules section, but is it possible to configure app following way:

• use squash merge for pull requests having "merge" label
• use merge commit for pull requests having "release-merge" label

[davidvavra]

Same question here. Documentation for rules is not clear - from examples it looks you can only make multiple options and if any of them is satisfied, it's merged (OR). Can you combine some rules with OR and some with AND?

[Tapchicoma]

I've ended up using second instance of bot for merge commits additionally to the squash ones 😒

[davidvavra]

I'm thinking of workaround of using the bot only for pull requests ("merge" label) and merging manually for releases ("merge-release" label)

[RoystonS]

You can't do this out-of-the-box. I've added an implementation of this in a local fork but haven't had time to propose a PR back for it yet.

What we've done:

We've added a mergeMethodLabelMap configuration option that maps labels to merge methods. (Behaviour is undefined if multiple labels map to conflicting methods.)

So we have something like:

rules:
  - requiredLabels:
      - autosquash
  - requiredLabels:
      - autorebase

mergeMethodLabelMap:
  autosquash: squash
  autorebase: rebase

in our configuration. i.e. in order to merge you must supply either autosquash or autorebase, and then we select merge strategy based on which one.

I could probably get a PR together if there's interest?

[bobvanderlinden]

It would be nicer if you could place mergeMethod within rules. That way you can alter the mergeMethod based on all conditions. This could also be a first step to move mergeCommitMessage to rules as well. If people want to have mergemethod based on label I can very well imagine that there are other conditions on which mergeMethod (and others) need to be able to rely.

Example:

rules:
  - requiredLabels:
      - autosquash
    mergeMethod: squash
  - requiredLabels:
      - autorebase
    mergeMethod: rebase
# ... global merge conditions
mergeMethod: merge

The same pattern can be used for [rebase] in title and conditions like that.

What do you think?

I agree that the rules are not always clear, but I think that's mostly a documentation issue. Any suggestions are welcome. Basically:

Global conditions need to be met AND conditions of any of the rules need to be met.
With the addition of mergeMethod in rules you can override the global mergeMethod if that rule's conditions are met.

[RoystonS]

@bobvanderlinden Yes, that's really nice, and, as you say, it extends to all condition types so is much more flexible. I'll get something together.

[RoystonS]

The code gets a little messy with the combination of conditions and config at the same level.

I can either take the rule object (consisting of conditions plus bits of config) and filter it down to only the configurable portions (e.g. mergeMethod and future additions) or I can move the configuration portion deeper down inside the rule object to keep it separated from the conditions. e.g.:

rules:
  - requiredLabels:
      - autosquash
    mergeMethod: squash
  - requiredLabels:
      - autorebase
    config:
      mergeMethod: rebase

# ... global merge conditions
mergeMethod: merge

Do you have a preference, @bobvanderlinden?

[sebastiankirsch]

Any progress on this?