Skip to content

Commit

Permalink
chore(release): set up conventional commit changelog tool. Part of #3920
Browse files Browse the repository at this point in the history
 (#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
  • Loading branch information
Bobgy committed Jul 2, 2020
1 parent 91d4e50 commit 1930103
Show file tree
Hide file tree
Showing 10 changed files with 2,459 additions and 51 deletions.
13 changes: 12 additions & 1 deletion .github/pull_request_template.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).)

70 changes: 70 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion VERSION
Original file line number Diff line number Diff line change
@@ -1 +1 @@
1.0.0-rc.2
1.0.0-rc.2
13 changes: 8 additions & 5 deletions hack/check-release-needed-tools.sh
Original file line number Diff line number Diff line change
Expand Up @@ -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"
Expand Down
13 changes: 12 additions & 1 deletion hack/release-imp.sh
Original file line number Diff line number Diff line change
Expand Up @@ -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/.."
Expand All @@ -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
Expand Down
2 changes: 1 addition & 1 deletion hack/release.sh
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
Loading

0 comments on commit 1930103

Please sign in to comment.