feat: Use Conventional Commits for release management/PRs

.github/workflows/cla.yml

@@ -15,7 +15,7 @@ on:
 
 jobs:
   CLAssistant:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
     if: ${{ github.repository_owner == 'deephaven' }}
     steps:
       - name: 'CLA Assistant'

.github/workflows/conventional-pr-check.yml

@@ -0,0 +1,40 @@
+name: 'Conventional PR'
+
+on:
+  pull_request_target:
+    types:
+      - opened
+      - edited
+      - synchronize
+
+jobs:
+  pr-check:
+    name: Validate PR title
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        id: lint_pr_title
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - uses: marocchino/sticky-pull-request-comment@v2
+        # When the previous steps fails, the workflow would stop. By adding this
+        # condition you can continue the execution with the populated error message.
+        if: always() && (steps.lint_pr_title.outputs.error_message != null)
+        with:
+          header: pr-title-lint-error
+          message: |
+            Pull Request titles must follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/).
+
+            Details:
+
+            ```
+            ${{ steps.lint_pr_title.outputs.error_message }}
+            ```
+
+      # Delete a previous comment when the issue has been resolved
+      - if: ${{ steps.lint_pr_title.outputs.error_message == null }}
+        uses: marocchino/sticky-pull-request-comment@v2
+        with:
+          header: pr-title-lint-error
+          delete: true

.github/workflows/publish-alpha.yml

@@ -12,7 +12,7 @@ on:
         default: ''
 jobs:
   publish-alpha:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
     permissions:
       contents: read
       packages: write

.github/workflows/publish-nightly.yml

@@ -7,7 +7,7 @@ on:
     - cron: '0 6 * * *'
 jobs:
   check_date:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
     name: Check latest commit
     outputs:
       should_run: ${{ steps.should_run.outputs.should_run }}
@@ -24,7 +24,7 @@ jobs:
   publish-nightly:
     needs: check_date
     if: ${{ needs.check_date.outputs.should_run != 'false' }}
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
     permissions:
       contents: read
       packages: write

.github/workflows/publish-packages.yml

@@ -5,7 +5,7 @@ on:
     types: [created]
 jobs:
   publish-packages:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
     permissions:
       contents: read
       packages: write

CONTRIBUTING.md

@@ -37,21 +37,33 @@ Over time, forks will get out of sync with the upstream repository. To stay up t
 
 ## Creating a Pull Request
 
-1) Follow the GitHub instructions for [Creating a Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
+1. Follow the GitHub instructions for [Creating a Pull Request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request).
    - Use `deephaven/web-client-ui` as the base repository.
    - Use your own fork, `<username>/web-client-ui` as the repository to push to.
-2) Fill in the information in the Pull Request:
+2. Fill in the information in the Pull Request:
    - If you know people who should be reviewers, add them as a reviewer
    - Add yourself as the Assignee
-   - Select one label depending on the change type:
-      - `bug`: Fixing a bug in an existing feature
-      - `enhancement`: Adding a new feature
-      - `internal`: Changes to the project config or build
-      - `documentation`: Documentation change only
-   - **Breaking Changes:** if your change breaks an existing API in such a way that users of the package affected will need to make some changes to migrate to the newer version, add the `breaking` label to the PR and include a section in the description saying `## Breaking Changes` and any migration instructions required.
+   - PR titles must follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/).
+     - The `type` provided must be one of [commitizen conventional commit types](https://github.com/commitizen/conventional-commit-types):
+       - **feat**: A new feature
+       - **fix**: A bug fix
+       - **docs**: Documentation only changes
+       - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+       - **refactor**: A code change that neither fixes a bug nor adds a feature
+       - **perf**: A code change that improves performance
+       - **test**: Adding missing tests or correcting existing tests
+       - **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+       - **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+       - **chore**: Other changes that don't modify src or test files
+       - **revert**: Reverts a previous commit
+     - The `scope` is not required.
+   - **BREAKING CHANGE:** if your change breaks an existing API in such a way that users of the package affected will need to make some changes to migrate to the newer version, add the `BREAKING CHANGE:` footer to the PR description, detailing the breakage and any migration instructions necessary, e.g.:
+   ```
+   BREAKING CHANGE: The API now takes a new parameter that must be provided.
+   ```
+   - **NOTE:** Do _not_ use the `!` notation for marking a breaking change - you must use the `BREAKING CHANGE:` footer and include details of the breakage/migration.
    - [Link the PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) with any associated issues
-3) Submit the PR
-
+3. Submit the PR
 
 ## Deephaven Contributor License Agreement (CLA)
 

README.md

@@ -75,19 +75,15 @@ If you encounter an issue specific to a browser, check that your browser is up t
 
 ## Releasing a New Version
 
-When releasing a new version, you need to commit a version bump, then tag and create the release. By creating the release, the [publish-packages action](.github/workflows/publish-packages.yml) will be triggered, and will automatically publish the packages. Some of these steps below also make use of the [GitHub CLI](https://github.com/cli/cli)
-
-1. Bump the version:
-   - Run `npm run version-bump`. Select the type of version bump ([patch, minor, or major version](https://semver.org/)). Remember the version for the next steps, and fill it in instead of `<version>` (should be in semver format with `v` prefix, e.g. `v0.7.1`).
-   - Commit your changes. `git commit --all --message="Version Bump <version>"`
-   - Create a pull request. `gh pr create --fill --web`
-   - Approve the pull request and merge to `main`.
-2. Generate the changelog:
-   - Generate a [GitHub Personal access token](https://github.com/settings/tokens) with the `public_repo` scope. Copy this token and replace `<token>` with it below.
-   - Generate the changelog: `GITHUB_AUTH=<token> npm run changelog --silent -- --next-version=<version> > /tmp/changelog_<version>.md`
-3. Create the tag. Use the command line to create an annotated tag (lightweight tags will not work correctly with lerna-changelog): `git tag --annotate <version> --file /tmp/changelog_<version>.md`
-4. Push the tag: `git push origin <version>`
-5. Create the release: `gh release create <version> --notes-file /tmp/changelog_<version>.md --title <version>`
+We use [lerna](https://github.com/lerna/lerna) and [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to automatically handle incrementing the version, generate the changelog, and create the release.
+
+1. Generate a [GitHub Personal access token](https://github.com/settings/tokens):
+
+- Under `Repository Access`, select `Only select repositories` and add `deephaven/web-client-ui`.
+- Under `Repository Permissions`, set `Access: Read and write` for `Contents`. This will be necessary to push your version bump and create the release.
+- Copy the token created and replace `<token>` with it in the next step.
+
+2. Bump the version, update the changelog, and create a release: `GH_TOKEN=<token> npm run version-bump`
 
 After the release is created, you can go to the [actions page](https://github.com/deephaven/web-client-ui/actions) to see the publish action being kicked off.