[Feature Discussion] - Cascading Auto-Merge

[jefeish]

Extending the Probot Auto-Merge App with a Cascading Release Merge Feature

Description

The Cascading Auto Merge feature merges release branches by the order of their semantic version. It only operates on branch prefixes specified in the App config Yaml. This feature should help to keep release branches (or any other specified branch group) in sync.

---

Use-case

To explain the Cascading Auto Merge functionality a little bit more detailed, here is some example.

• Lets say an organization has the following release branch structure in their Repository.

  Branches
  master
  development
  release/0.1
  release/1.1-rc.1
  release/1.1
  release/1.2
  release/2.0
  release/2.0.1-alpha
  release/2.0.1-beta
  release/2.0.1-beta.1

---

• Now a developer makes a change to the release/1.1 branch and issues a PR against the development branch, requesting at least one approval.

• With the Cascading Auto Merge functionality support the following should happen.

  Up on PR approval, the release/1.1 branch gets auto-merged into the development branch and in addition the release/1.1 branch gets forward auto-merged in to subsequent releases based on their semantic version order.

  This sample output should demonstrate the expected GitHub behavior

  

---

• In the original GitHub PR you will see comments for each subsequent cascading merge PR, including links to these PRs, providing a full audit trail of automated merges.

  Below is a sample output of a test run.

  

---

Merge-Scenarios

A couple of merge scenarios and the resulting behavior of the cascading auto-merge feature.
(Assuming that feature and release are defined as merge prefixes)

---

Supported-Branch-Versioning

The following will give some examples on the supported semantic versions

Reference: Semantic Versioning

A semantic version number - MAJOR.MINOR.PATCH

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backwards compatible manner
• PATCH version when you make backwards compatible bug fixes

Additional labels for pre-release and build metadata

These are available as extensions to the MAJOR.MINOR.PATCH format.

Extensions	+ Version
alpha	alpha.1
beta	beta.1
rc	rc.1

Version-Syntax

<Branch-Prefix>/<MAJOR>.<MINOR>.<PATCH>-[ alpha | beta | rc ].<version>

The Branch-Prefix is specific to our implementation

---

Some examples for versions and their priority

In these examples we omit the Branch-Prefix

Standard versioning

Example
1.1.0 < 1.1.2 < 1.2.0 < 1.2.1 < 1.3.0 < 2.0.0

Pre-release fields

Example
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

---

Branch Naming Examples

• release/1.1.0
• release/1.2.0-beta
• feature/1.1.0-alpha.1

[bobvanderlinden]

Thanks for the extensive description of the feature!

Up on PR approval, the release/1.1 branch gets auto-merged into the development branch and in addition the release/1.1 branch gets forward auto-merged in to subsequent releases based on their semantic version order.

From your screenshot it seems that auto-merge would create new pull requests for the subsequent PRs? That does make sense to let CI do its thing.

If so, I think that is outside the scope of auto-merge. auto-merge can still be used to automatically merge the subsequence PRs after they were created, but creating those PRs seems like a task for a different app/bot. Maybe even a github action.

I also think the comments that are reported back in the original PR should not be part of auto-merge. Whenever one of the subsequent PRs is manually merged, the comments should still show up in the original PR. A trigger on a PR that are merged and looking up the original PR where to post a comment should be possible without auto-merge.

[rogerluan]

auto-merge can still be used to automatically merge the subsequence PRs after they were created

I agree 👍

I've been using auto-merge to merge multiple chained (cascade) PRs in a row for years, and hasn't been an issue to me