Skip to content

Commit eca0188

Browse files
authored
Merge pull request #1 from maikuru/release/1.1.0
Updated Readme Documentation
2 parents ae7fc65 + 5e88116 commit eca0188

File tree

1 file changed

+66
-3
lines changed

1 file changed

+66
-3
lines changed

README.md

Lines changed: 66 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,38 +1,101 @@
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+
259

3-
This action is intended to be triggered by a merge and find the next version branch to merge
4-
the combined merge into.
560

661
## Inputs
762

863
### `production-branch`
64+
965
The primary branch matching the production environment. Default `"master"`.
1066

1167
### `development-branch`
68+
1269
The branch where active development is integrated into. Default `"develop"`.
1370

1471
### `release-pattern`
72+
1573
The Release Branch naming pattern. Default `"'release/'"`.
1674

1775
### `merge-message-template`
76+
1877
Template to generate the commit message
1978
Default: `'Auto Merged {source_branch} into {target_branch}'`
2079

2180
### `pr-on-failed-merge`
81+
2282
(yes/no) If a merge fails, create a pull request instead.
2383
Default: yes
2484

2585
### `pr-title-template`
86+
2687
Template to generate a PR title from, only used when `pr-on-failed-merge` is set to `yes`
2788
Default: `'Failed Auto Merged {source_branch} into {target_branch}'`
2889

2990
## Environment Variables used,
91+
3092
* `GITHUB_API_URL`
3193
* `GITHUB_TOKEN`
3294

3395
## Outputs
3496

3597
### `details`
98+
3699
Short description of the actions taken by this Action
37100

38101

0 commit comments

Comments
 (0)