Add tag command, update guide, add PR templates (#2679)

.github/PULL_REQUEST_TEMPLATE/default.md

@@ -0,0 +1,5 @@
+Fixes #
+
+**Description of changes:**
+
+-

.github/PULL_REQUEST_TEMPLATE/release.md

@@ -0,0 +1,13 @@
+## Changes since v
+
+## 🚀 Features
+
+*
+
+## 🐛 Bug Fixes
+
+*
+
+## 🧰 Maintenance
+
+*

Makefile

@@ -41,6 +41,10 @@ lint:
 release-version:
 	npm version $(CMD_ARGS) --git-tag-version false
 
+.PHONY: tag-release
+tag-release:
+	scripts/tag-release.sh
+
 .PHONY: test
 test: binaries/client
 	yarn run jest $(or $(CMD_ARGS), "src")

RELEASE_GUIDE.md

@@ -2,10 +2,20 @@
 
 Lens releases are built by CICD automatically on git tags. The typical release process flow is the following:
 
-1. Create a release branch `release/v{version}` from `master` branch or from existing release branch (for example, `release/v3.5`) on patch releases.
-2. Update changelog in `static/RELEASE_NOTES.md` and bump version in `package.json`.
-3. Create PR and put change log in description field.
-4. After the PR is accepted, create a tag from release branch.
-5. Push tag to GitHub.
-6. Publish automatically created GitHub release.
-7. Merge the release PR after the release is published and delete the release branch from GitHub.
+1. From a clean and up to date `master` run `make release-version <version-type>` where `<version-type>` is one of the following:
+    - `major`
+    - `minor`
+    - `patch`
+    - `premajor`
+    - `preminor`
+    - `prepatch`
+    - `prerelease [--preid=<prerelease-id>]`
+      - where `<prerelease-id>` is generally one of:
+        - `alpha`
+        - `beta`
+        - `rc`
+1. Create PR (git should have printed a link to GitHub in the console) with the contents of all the accepted PRs since the last release.
+1. After the PR is accepted and passes CI. Go to the same branch and run `make tag-release`
+1. Once CI passes again go to the releases tab on GitHub, create a new release from the tag that was created, make sure that the change log is the same as that of the PR.
+1. Merge the release PR after the release is published. GitHub should delete the branch once it is merged.
+1. If you have just released a new major or minor version then create a new `vMAJOR.MINOR` branch from that same tag and push it to master. This will be the target for future patch releases and shouldn't be deleted.

package.json

@@ -43,7 +43,7 @@
     "version-checkout": "cat package.json | jq '.version' -r | xargs printf \"release/v%s\" | xargs git checkout -b",
     "version-commit": "cat package.json | jq '.version' -r | xargs printf \"release v%s\" | git commit --no-edit -s -F -",
     "version": "yarn run version-checkout && git add package.json && yarn run version-commit",
-    "postversion": "git push --set-upstream origin release/v$npm_package_version"
+    "postversion": "git push --set-upstream ${GIT_REMOTE:-origin} release/v$npm_package_version"
   },
   "config": {
     "bundledKubectlVersion": "1.18.15",

scripts/tag-release.sh

@@ -0,0 +1,10 @@
+#!/bin/bash
+
+if [[ ${git branch --show-current} =~ ^release/v ]]
+then
+  VERSION_STRING=$(cat package.json | jq '.version' -r | xargs printf "v%s")
+  git tag ${VERSION_STRING}
+  git push ${GIT_REMOTE:-origin} ${VERSION_STRING}
+else
+  echo "You must be in a release branch"
+fi