chore(release): set up conventional commit changelog tool. Part of ku…

…beflow#3920 (kubeflow#4033)

* chore(release): set up conventional-commits/standard-version

* chore(release): add contribution doc and PR template for conventional PR title

* Example changelog

* Revert "Example changelog"

This reverts commit bf5136c.

* Fix VERSION having extra line ending

* Add urls to CHANGELOG.md

* Add script to fix changelog format

* Revert "Add urls to CHANGELOG.md"

This reverts commit de82f4c.

* Integrate changelog process into release-imp.sh

* Updated according to @joeliedtke's suggestions

.github/pull_request_template.md

@@ -2,10 +2,21 @@
 
 
 **Checklist:**
+- [ ] The title for your pull request (PR) should follow our title convention. [Learn more about the pull request title convention used in this repository](https://github.com/kubeflow/pipelines/blob/master/CONTRIBUTING.md#pull-request-title-convention). 
+
+   PR titles examples:
+    * `fix(frontend): fixes empty page. Fixes #1234`
+       Use `fix` to indicate that this PR fixes a bug.
+    * `feat(backend): configurable service account. Fixes #1234, fixes #1235`
+       Use `feat` to indicate that this PR adds a new feature. 
+    * `chore: set up changelog generation tools`
+       Use `chore` to indicate that this PR makes some changes that users don't need to know.
+    * `test: fix CI failure. Part of #1234`
+        Use `part of` to indicate that a PR is working on an issue, but shouldn't close the issue when merged.
+
 - [ ] Do you want this pull request (PR) cherry-picked into the current release branch?
 
     If yes, use one of the following options:
 
     * **(Recommended.)** Ask the PR approver to add the `cherrypick-approved` label to this PR. The release manager adds this PR to the release branch in a batch update.
     *  After this PR is merged, create a cherry-pick PR to add these changes to the release branch. (For more information about creating a cherry-pick PR, see the [Kubeflow Pipelines release guide](https://github.com/kubeflow/pipelines/blob/master/RELEASE.md#option--git-cherry-pick).)
-

CONTRIBUTING.md

@@ -28,6 +28,76 @@ use GitHub pull requests for this purpose. Consult
 [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
 information on using pull requests.
 
+## Pull Request Title Convention
+
+We enforce a pull request (PR) title convention to quickly indicate the type and scope of a PR.
+PR titles become commit messages when PRs are merged. We also parse PR titles to generate the changelog.
+
+PR titles should:
+* Provide a user-friendly description of the change.
+* Follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/).
+* Specifies issue(s) fixed, or worked on at the end of the title.
+
+Examples:
+* `fix(ui): fixes empty page. Fixes #1234`
+* `feat(backend): configurable service account. Fixes #1234, fixes #1235`
+* `chore: refactor some files`
+* `test: fix CI failure. Part of #1234`
+
+The following sections describe the details of the PR title convention.
+
+### PR Title Structure
+PR titles should use the following structure.
+```
+<type>[optional scope]: <description>[ Fixes #<issue-number>]
+```
+
+Replace the following:
+
+*  **`<type>`**: The PR type describes the reason for the change, such as `fix` to indicate that the PR fixes a bug. More information about PR types is available in the next section. 
+*  **`[optional scope]`**: (Optional.) The PR scope describes the part of Kubeflow Pipelines that this PR changes, such as `frontend` to indicate that the change affects the user interface. Choose a scope according to [PR Scope section](#pr-scope).
+*  **`<description>`**: A user friendly description of this change.
+*  **`[ Fixes #<issues-number>]`**: (Optional.) Specifies the issues fixed by this PR.
+
+### PR Type
+Type can be one of the following:
+* **feat**: A new feature.
+* **fix**: A bug fix. However, a PR that fixes test infrastructure is not user facing, so it should use the test type instead.
+* **docs**: Documentation changes.
+* **chore**: Anything else that does not need to be user facing.
+* **test**: Adding or updating tests only. Please note, **feat** and **fix** PRs should have related tests too.
+* **refactor**: A code change that neither fixes a bug nor adds a feature.
+* **perf**: A code change that improves performance.
+
+Note, only feature, fix and perf type PRs will be included in CHANGELOG, because they are user facing.
+
+If you think the PR contains multiple types, you can choose the major one or
+split the PR to focused sub-PRs.
+
+If you are not sure which type your PR is and it does not have user impact,
+use `chore` as the fallback.
+
+### PR Scope
+Scope is optional, it can be one of the following:
+* **frontend**: user interface or frontend server related, folder `frontend`, `frontend/server`
+* **backend**: Backend, folder `backend`
+* **sdk**: `kfp` python package, folder `sdk`
+* **sdk/client**: `kfp-server-api` python package, folder `backend/api/python_http_client`
+* **components**: Pipeline components, folder `components`
+* **deployment**: Kustomize or gcp marketplace manifests, folder `manifests`
+* **metadata**: Related to machine learning metadata (MLMD), folder `backend/metadata_writer`
+* **cache**: Caching, folder `backend/src/cache`
+* **swf**: Scheduled workflow, folder `backend/src/crd/controller/scheduledworkflow`
+* **viewer**: Tensorboard viewer, folder `backend/src/crd/controller/viewer`
+
+If you think the PR is related to multiple scopes, you can choose the major one or
+split the PR to focused sub-PRs. Note, splitting large PRs that affect multiple
+scopes can help make it easier to get your PR reviewed, since different scopes
+usually have different reviewers.
+
+If you are not sure, or the PR doesn't fit into above scopes. You can either
+omit the scope because it's optional, or propose an additional scope here.
+
 ## Community Guidelines
 
 This project follows

VERSION

@@ -1 +1 @@
-1.0.0-dev.2
+1.0.0-dev.2

hack/check-release-needed-tools.sh

@@ -17,18 +17,21 @@
 set -e
 
 echo "The following tools are needed when releasing KFP:"
+echo "node==12"
+which node >/dev/null || (echo "node not found in PATH, recommend install via https://github.com/nvm-sh/nvm#installing-and-updating" && exit 1)
+node -v | grep v12 || (echo "node not v12.x version" && exit 1)
 echo "jq>=1.6"
-which jq || (echo "jq not found in PATH" && exit 1)
+which jq >/dev/null || (echo "jq not found in PATH" && exit 1)
 echo "yq>=3.3"
-which yq || (echo "yq not found in PATH" && exit 1)
+which yq >/dev/null || (echo "yq not found in PATH" && exit 1)
 yq -V | grep 3. || (echo "yq version 3.x should be used" && exit 1)
 echo "java>=8"
-which java || (echo "java not found in PATH" && exit 1)
+which java >/dev/null || (echo "java not found in PATH" && exit 1)
 echo "bazel==0.24.0"
-which bazel || (echo "bazel not found in PATH" && exit 1)
+which bazel >/dev/null || (echo "bazel not found in PATH" && exit 1)
 bazel version | grep 0.24.0 || (echo "bazel not 0.24.0 version" && exit 1)
 echo "python>3"
-which python || (echo "python not found in PATH" && exit 1)
+which python >/dev/null || (echo "python not found in PATH" && exit 1)
 python -c "import setuptools" || (echo "setuptools should be installed in python" && exit 1)
 
 echo "All tools installed"

hack/release-imp.sh

@@ -16,7 +16,10 @@
 
 set -ex
 
-echo "Usage: edit kubeflow/pipelines/VERSION to new version tag first, then run this script."
+echo "Usage: update kubeflow/pipelines/VERSION to new version tag by"
+echo '`echo -n "\$VERSION" > VERSION` first, then run this script.'
+echo "Please use the above command to make sure the file doesn't have extra"
+echo "line endings."
 
 DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" > /dev/null && pwd)"
 REPO_ROOT="$DIR/.."
@@ -29,6 +32,14 @@ fi
 
 "$DIR/check-release-needed-tools.sh"
 
+pushd "$REPO_ROOT"
+npm ci
+npm run changelog
+popd
+# Change github issue/PR references like #123 to real urls in markdown.
+# The issues must have a " " or a "(" before it to avoid already converted issues like [\#123](url...).
+sed -i.bak -e 's|\([ (]\)#\([0-9]\+\)|\1[\\#\2](https://github.com/kubeflow/pipelines/issues/\2)|g' "$REPO_ROOT/CHANGELOG.md"
+
 "$REPO_ROOT/components/release-in-place.sh" $TAG_NAME
 "$REPO_ROOT/manifests/gcp_marketplace/hack/release.sh" $TAG_NAME
 "$REPO_ROOT/manifests/kustomize/hack/release.sh" $TAG_NAME

hack/release.sh

@@ -31,7 +31,7 @@ git clone "git@github.com:${REPO}.git" "$clone_dir"
 cd "$clone_dir"
 git checkout "$BRANCH"
 
-echo "$TAG_NAME" > ./VERSION
+echo -n "$TAG_NAME" > ./VERSION
 # Run the release script in cloned repo
 "hack/release-imp.sh" $TAG_NAME