ci: Add Conventional Commit Linter

.commit-me.json

@@ -0,0 +1,4 @@
+{
+  "include-pull-requests": true,
+    "types": [ "chore", "ci", "docs", "feat", "fix", "perf", "refactor", "release", "revert", "squash", "style", "test" ]
+}

.github/workflows/conventional-commits.yaml

@@ -0,0 +1,32 @@
+name: Conventional Commits Validation
+
+on:
+  workflow_dispatch:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+      - reopened
+      - edited
+
+permissions:
+  contents: read
+  pull-requests: read
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}  # Ensure that only one instance of this workflow is running per Pull Request
+  cancel-in-progress: true  # Cancel any previous runs of this workflow
+
+jobs:
+  validate-commits:
+    name: Conventional Commits Validation
+    runs-on: ubuntu-latest
+    steps:
+      - uses: dev-build-deploy/[email protected]
+        env:
+          FORCE_COLOR: 3
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          include-commits: false
+          update-labels: false
+          config: ".commit-me.json"

CONTRIBUTING.md

@@ -132,7 +132,7 @@ merging.
 All commits to the main repository should follow the
 [conventional commit](https://conventionalcommits.org) standard. In a nutshell,
 this means commit messages should begin with a semantic tag such as `feat:`,
-`fix:`, `docs:`, `tests:`, or `refactor:`. Our release tooling uses these tags
+`fix:`, `docs:`, `test:`, `refactor:`, etc... Our release tooling uses these tags
 to determine the semantics of your commit, such as how it affects semantic
 versioning of the libraries, and to generate changelogs from commit
 descriptions. If you are not familiar with conventional commits, please review