ci: introduce conventional commits & commitlint

.github/workflows/commitlint.yml

@@ -0,0 +1,41 @@
+name: CI
+
+on: [push, pull_request]
+
+permissions:
+  contents: read
+
+jobs:
+  commitlint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: lts/*
+
+      - name: Install commitlint
+        run: npm install -D @commitlint/cli @commitlint/config-conventional
+
+      - name: Setup commitlint
+        run: |
+          echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
+
+      - name: Print versions
+        run: |
+          git --version
+          node --version
+          npm --version
+          npx commitlint --version
+
+      - name: Validate current commit (last commit) with commitlint
+        if: github.event_name == 'push'
+        run: npx commitlint --last --verbose
+
+      - name: Validate PR commits with commitlint
+        if: github.event_name == 'pull_request'
+        run: npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose

CONTRIBUTING.md

@@ -119,25 +119,13 @@ mkdocs build --strict
 
 ## Commit Message
 
-Read
-[Git Contribution Guidelines](https://git-scm.com/docs/SubmittingPatches#describe-changes).
-
-In a nutshell:
-
-- **First Line**: `component: description of the patch` in all lowercase
-  unless it's in a cap in the code.
-- **Body**: In 2-3 paragraphs:
-  1. the current problem you want to solve
-  2. justification of your change
-  3. if any, alternative solutions considered but discarded
+Follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
 
 ## Pull Request Style
 
-1. **Title**: Follow the First Line rule of [Commit Message](#commit-message).
-2. **Description**: Follow the Body rule of [Commit Message](#commit-message).
-3. **CI**: Verify that all CI checks pass on your fork before submitting the
+1. **CI**: Verify that all CI checks pass on your fork before submitting the
    PR.  Avoid relying on the CI of this repository to catch errors, as this
    can cause delays or stalls for other contributors.
-4. **Commits**: There is no need to squash commits within the PR
+2. **Commits**: There is no need to squash / force push commits within the PR
    unless explicitly requested.  Keeping separate commits can help reviewers
    understand the progression of changes.