Update github workflow to update changelog on every PR merge (#108)

* Add changelog file and update github workflow to update it when PR merges to master

* Test changelog updater

* Revert "Test changelog updater"

This reverts commit eb694f4.

* Add a reference to release

* Add a reference to release

.github/pull_request_template.md

@@ -20,7 +20,7 @@ change is, and why it is being made, with enough context for anyone to understan
 ### Release planning
 
 - [ ] I've decided if this PR requires a new major/minor/patch version accordingly to
-    [semver](https://semver.org/), and I've changed the name of the BRANCH to release/* , feature/* or patch/* .
+    [semver](https://semver.org/), and I've changed the name of the BRANCH to major/* , minor/* or patch/* .
 </details>
 
 ### What

.github/workflows/release.yml

@@ -43,14 +43,14 @@ jobs:
           CURRENT_VERSION="${{ steps.gettag.outputs.TAG }}"
           CURRENT_VERSION="${CURRENT_VERSION#v}"  # Remove the 'v' from the start of the version
           IFS='.' read -ra VERSION_PARTS <<< "$CURRENT_VERSION"
-          if [[ $BRANCH_NAME =~ ^release/ ]]; then
+          if [[ $BRANCH_NAME =~ ^major/ ]]; then
             VERSION_PARTS[0]=$((VERSION_PARTS[0] + 1))
             VERSION_PARTS[1]=0
             VERSION_PARTS[2]=0
-          elif [[ $BRANCH_NAME =~ ^feature/ ]]; then
+          elif [[ $BRANCH_NAME =~ ^minor/ ]]; then
             VERSION_PARTS[1]=$((VERSION_PARTS[1] + 1))
             VERSION_PARTS[2]=0
-          elif [[ $BRANCH_NAME =~ ^patch/ ]]; then
+          else
             VERSION_PARTS[2]=$((VERSION_PARTS[2] + 1))
           fi
           NEXT_VERSION="v${VERSION_PARTS[0]}.${VERSION_PARTS[1]}.${VERSION_PARTS[2]}"

CHANGELOG.md

@@ -0,0 +1 @@
+Please refer to https://github.com/stellar/stellar-dbt-public/releases

README.md

@@ -7,8 +7,8 @@ If you're interested in setting up your own dbt project, you can find detailed i
 
 Pay attention, it is very important to know if your modification to this repository is a release (breaking changes), a feature (functionalities) or a patch(to fix bugs). With that information, create your branch name like this:
 
-- `release/<branch-name>`
-- `feature/<branch-name>`
+- `major/<branch-name>`
+- `minor/<branch-name>`
 - `patch/<branch-name>`
 
 If branch is already made, just rename it _before passing the pull request_.