build: use matching commitlint config

The commit conventions enforced by commitlint (conventional) were different than the conventions used by the semantic-release (angular). In practice, is was never a problem as they are pretty similar, but it's better to be consistent anyways. Update the commit conventions documentation according to the change and also extend it with the information about which kind of release is triggered by which commit type. Add explicit configuration for release rules for semantic-release to the configuration file - rules are the same as before, but now it is easier to see what they actually are.
karma-runner · Nov 1, 2021 · 829d9ef · 829d9ef
1 parent 920fa33
commit 829d9ef
Show file tree

Hide file tree

Showing 5 changed files with 53 additions and 30 deletions.
diff --git a/commitlint.config.js b/commitlint.config.js
@@ -1 +1 @@
-module.exports = { extends: ['@commitlint/config-conventional'] }
+module.exports = { extends: ['@commitlint/config-angular'] }
diff --git a/docs/dev/06-git-commit-msg.md b/docs/dev/06-git-commit-msg.md
@@ -2,16 +2,18 @@
 showInMenu: false
 ---
 
+In the repository we use and enforce the commit message conventions. The conventions are verified using [commitlint] with [Angular config](https://www.npmjs.com/package/@commitlint/config-angular).
+
 ## The reasons for these conventions:
 - automatic generating of the changelog
 - simple navigation through git history (e.g. ignoring style changes)
 
 ## Format of the commit message:
 ```bash
 <type>(<scope>): <subject>
-
+<BLANK LINE>
 <body>
-
+<BLANK LINE>
 <footer>
 ```
 
@@ -27,19 +29,18 @@ Fixes #2310
 ```
 
 ## Message subject (first line)
-The first line cannot be longer than 70 characters, the second line is always blank and
-other lines should be wrapped at 80 characters. The type and scope should
-always be lowercase as shown below.
+The first line cannot be longer than 72 characters and should be followed by a blank line. The type and scope should always be lowercase as shown below.
 
 ### Allowed `<type>` values:
 
-* **feat** (new feature for the user, not a new feature for build script)
-* **fix** (bug fix for the user, not a fix to a build script)
-* **docs** (changes to the documentation)
-* **style** (formatting, missing semi colons, etc; no production code change)
-* **refactor** (refactoring production code, eg. renaming a variable)
-* **test** (adding missing tests, refactoring tests; no production code change)
-* **chore** (updating grunt tasks etc; no production code change)
+* **feat** for a new feature for the user, not a new feature for build script. Such commit will trigger a release bumping a MINOR version.
+* **fix** for a bug fix for the user, not a fix to a build script. Such commit will trigger a release bumping a PATCH version.
+* **perf** for performance improvements. Such commit will trigger a release bumping a PATCH version.
+* **docs** for changes to the documentation.
+* **style** for formatting changes, missing semicolons, etc.
+* **refactor** for refactoring production code, e.g. renaming a variable.
+* **test** for adding missing tests, refactoring tests; no production code change.
+* **build** for updating build configuration, development tools or other changes irrelevant to the user.
 
 ### Example `<scope>` values:
 
@@ -55,16 +56,9 @@ The `<scope>` can be empty (e.g. if the change is a global or difficult
 to assign to a single component), in which case the parentheses are
 omitted. In smaller projects such as Karma plugins, the `<scope>` is empty.
 
-
 ## Message body
-* uses the imperative, present tense: “change” not “changed” nor “changes”
-* includes motivation for the change and contrasts with previous behavior
-
-For more info about message body, see:
-
-* https://365git.tumblr.com/post/3308646748/writing-git-commit-messages
-* https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
 
+Just as in the `<subject>`, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. Message body should include motivation for the change and contrasts with previous behavior.
 
 ## Message footer
 
@@ -91,10 +85,13 @@ To migrate your project, change all the commands, where you use `--port-runner`
 to `--runner-port`.
 ```
 
+Any commit with the breaking change section will trigger a MAJOR release and appear on the changelog independently of the commit type.
+
 ---
 
-This document is based on [AngularJS Git Commit Msg Convention]. See the
-[commit history] for examples of properly-formatted commit messages.
+This document is based on [Angular Commit Message Format]. See the [commit history] for examples of properly-formatted commit messages.
 
-[AngularJS Git Commit Msg Convention]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
+[commitlint]: https://conventional-changelog.github.io/commitlint/
+[Angular config]: https://www.npmjs.com/package/@commitlint/config-angular
+[Angular Commit Message Format]: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
 [commit history]: https://github.com/karma-runner/karma/commits/master
diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
@@ -445,7 +445,7 @@
   },
   "devDependencies": {
     "@commitlint/cli": "^12.1.4",
-    "@commitlint/config-conventional": "^12.1.4",
+    "@commitlint/config-angular": "^12.1.4",
     "@semantic-release/changelog": "^5.0.1",
     "@semantic-release/git": "^9.0.1",
     "browserify": "^16.2.3",

diff --git a/release.config.js b/release.config.js
@@ -20,5 +20,25 @@ module.exports = {
   success: [
     '@semantic-release/github',
     './tools/update-docs'
-  ]
+  ],
+
+  // The release rules determine what kind of release should be triggered
+  // based on the information included in the commit message. The default
+  // rules used by semantic-release are the same, but they are set explicitly
+  // for better visibility.
+  // See https://github.com/semantic-release/commit-analyzer/blob/master/lib/default-release-rules.js
+  releaseRules: [
+    { breaking: true, release: 'major' },
+    { revert: true, release: 'patch' },
+    { type: 'feat', release: 'minor' },
+    { type: 'fix', release: 'patch' },
+    { type: 'perf', release: 'patch' }
+  ],
+
+  // The preset determines which commits are included in the changelog and how
+  // the changelog is formatted. The default value used by semantic-release is
+  // the same, but it is set explicitly for visibility.
+  // See https://semantic-release.gitbook.io/semantic-release/#commit-message-format
+  // See https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular
+  preset: 'angular'
 }