|
1 | | -# downstream-version-automerge |
| 1 | +# Downstream Version Automerge |
| 2 | + |
| 3 | +Using [Semantic Versioning](https://semver.org/), creates a downstream hierarchy for your branches which then allows for an automated merge chain merging commits only to branches further down in the hierarchy. |
| 4 | + |
| 5 | +This means no more reduntant Pull Requests to merge code to your downstream branches. |
| 6 | + |
| 7 | +### WHAT IS IT DOING! ### |
| 8 | + |
| 9 | +Lets assume you have the following branch hierarchy: |
| 10 | + |
| 11 | +``` |
| 12 | +master (production-branch) |
| 13 | +|> hotfix/task-wtf-did-you-do |
| 14 | +|> release/1.2.4 |
| 15 | + |> bugfix/task-xyz |
| 16 | + |> release/1.3.0 |
| 17 | + |> feature/task-123 |
| 18 | + |> release/2.0.0 |
| 19 | + |> feature/task-456 |
| 20 | + |> develop (development-branch) |
| 21 | + |> project/golden-eye |
| 22 | +``` |
| 23 | + |
| 24 | +When you merge `hotfix/task-wtf-did-you-do` into `master` whether directly or via a Pull Request, this action will then attempt to merge the resulting `master` branch into `release/1.2.4` then if successful move on to merge `release/1.2.4` into `release/1.3.0`, then `release/1.3.0` into `release/2.0.0`, and finally `release/2.0.0` into `develop`. |
| 25 | + |
| 26 | +If at any point the action is unable to successfully merge the one of the branches then by default a Pull Request will be created in order for the development team to see where the merge conflict arose and resolve the issue. Once that Pull Request has been approved and merged that merge will effectively continue the auto-merge process where it failed before. |
| 27 | + |
| 28 | +### WHAT IT IS NOT DOING! |
| 29 | + |
| 30 | +This action is only focusing on the production, development, and release branches. All other branches are are ignored including branches that start with the release branch prefix, but are not Semenatic Version compatible. |
| 31 | + |
| 32 | +This means that as far as this action is concerned only these branches are in scope: |
| 33 | + |
| 34 | +``` |
| 35 | +master (production-branch) |
| 36 | +release/1.2.4 |
| 37 | +release/1.3.0 |
| 38 | +release/2.0.0 |
| 39 | +develop (development-branch) |
| 40 | +``` |
| 41 | + |
| 42 | +If you happen to have a branch that is not being picked up by this Action, then please refer to the [Node SemVer](https://www.npmjs.com/package/semver) library's documentation on what is a valid format as branches with invalid version identifiers are intentioanlly skipped. |
| 43 | + |
| 44 | +### WHY DO I NEED THIS? |
| 45 | + |
| 46 | +Sometimes you're just stuck having to support development of software following a non-agile trunk based development workflow. You might have version _1.2.3_ of your code in production on your `master` branch, version _1.3.0_ (`release/1.3.0`) being tested by your user acceptance team, and a major feature in the works that needs QA attention: _2.0.0_ (`release/2.0.0`), and just for the heck of it, you have a dumping ground branch `develop` where your team puts unscheduled bleading edge completed features. |
| 47 | + |
| 48 | +So you have a branch heirarchy that looks like this: |
| 49 | + |
| 50 | +``` |
| 51 | +master |
| 52 | + -> release/1.3.0 |
| 53 | + -> release/2.0.0 |
| 54 | + -> develop |
| 55 | +``` |
| 56 | + |
| 57 | +Now what happens when the User Acceptance team finds an issue that needs to be addressed? Normally you would have your team approve a Pull Request from your bugfix branch into the `release/1.3.0` branch then create 2 more pull requests to have `release/1.3.0` merged into `release/2.0.0` and lastly from `release/2.0.0` into `develop`. This has to be done in order and requires the development team to spent a frustrating amount of time reviewing pull requests for code they've already reviewed. |
| 58 | + |
2 | 59 |
|
3 | | -This action is intended to be triggered by a merge and find the next version branch to merge |
4 | | -the combined merge into. |
5 | 60 |
|
6 | 61 | ## Inputs |
7 | 62 |
|
8 | 63 | ### `production-branch` |
| 64 | + |
9 | 65 | The primary branch matching the production environment. Default `"master"`. |
10 | 66 |
|
11 | 67 | ### `development-branch` |
| 68 | + |
12 | 69 | The branch where active development is integrated into. Default `"develop"`. |
13 | 70 |
|
14 | 71 | ### `release-pattern` |
| 72 | + |
15 | 73 | The Release Branch naming pattern. Default `"'release/'"`. |
16 | 74 |
|
17 | 75 | ### `merge-message-template` |
| 76 | + |
18 | 77 | Template to generate the commit message |
19 | 78 | Default: `'Auto Merged {source_branch} into {target_branch}'` |
20 | 79 |
|
21 | 80 | ### `pr-on-failed-merge` |
| 81 | + |
22 | 82 | (yes/no) If a merge fails, create a pull request instead. |
23 | 83 | Default: yes |
24 | 84 |
|
25 | 85 | ### `pr-title-template` |
| 86 | + |
26 | 87 | Template to generate a PR title from, only used when `pr-on-failed-merge` is set to `yes` |
27 | 88 | Default: `'Failed Auto Merged {source_branch} into {target_branch}'` |
28 | 89 |
|
29 | 90 | ## Environment Variables used, |
| 91 | + |
30 | 92 | * `GITHUB_API_URL` |
31 | 93 | * `GITHUB_TOKEN` |
32 | 94 |
|
33 | 95 | ## Outputs |
34 | 96 |
|
35 | 97 | ### `details` |
| 98 | + |
36 | 99 | Short description of the actions taken by this Action |
37 | 100 |
|
38 | 101 |
|
|
0 commit comments