feat(commit-config): Commit Message Linting and Automation for TM-AP #73
Conversation
WalkthroughThis update introduces a commit message linting system using Commitlint, Husky, and Commitizen, enforced both locally via Git hooks and remotely through a GitHub Actions workflow. Configuration files for Commitlint and Commitizen are added, along with a Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant Git
participant Husky
participant Commitlint
participant GitHub
participant GitHub Actions
Developer->>Git: git commit
Git->>Husky: Trigger commit-msg hook
Husky->>Commitlint: Lint commit message
Commitlint-->>Husky: Pass/Fail result
Husky-->>Git: Allow or block commit
Developer->>GitHub: Push branch / open PR
GitHub->>GitHub Actions: Trigger commit-lint workflow
GitHub Actions->>Commitlint: Lint all PR commit messages
Commitlint-->>GitHub Actions: Pass/Fail result
GitHub Actions-->>GitHub: Update PR status
Possibly related issues
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
.gitignore (1)
61-63: Fix typo in ignore comment and confirm lockfile policy.The comment says
# Exclude pack-lock.jsonbut the file is namedpackage-lock.json. Please correct the typo:- # Exclude pack-lock.json + # Exclude package-lock.jsonAdditionally, many teams prefer committing the lockfile to ensure reproducible installs. Verify that excluding
package-lock.jsonaligns with your CI/CD strategy and team conventions..github/workflows/commit-lint.yml (1)
18-18: Add a newline at end of file.POSIX standards recommend ending text files with a newline. Please ensure there is a blank line at the end to avoid YAML or linter warnings.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 18-18: no new line character at the end of file
(new-line-at-end-of-file)
README.md (4)
47-49: Specify languages for fenced code blocks.To improve readability and syntax highlighting, add a language identifier (e.g.,
bashorshell) to your code fences. For example:- ``` + ```bash mvn clean install - ``` + ```Please apply the same for the Maven run and
npm ciblocks at lines 56–58 and 97–99.Also applies to: 56-58, 97-99
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
47-47: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
61-61: Remove or consolidate duplicate headings.There are two ## Usage sections at lines 61 and 123. Consider merging them or renaming one to avoid confusion for readers.
Also applies to: 123-123
31-31: Correct markdown link formatting.There’s an extra space before the URL in the link:
- follow this [guide] (https://piramal-swasthya.gitbook.io/amrit/developer-guide/development-environment-setup) + follow this [guide](https://piramal-swasthya.gitbook.io/amrit/developer-guide/development-environment-setup)🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
31-31: Bare URL used
null(MD034, no-bare-urls)
82-82: Align Node.js version with CI configuration.The GitHub Actions workflow uses Node.js 16. Consider updating the README prerequisite:
- Node.js (v14 or later) + Node.js (v16 or later)commitlint.config.js (1)
19-34: Consider Adding Scope Formatting Rules (Optional)
To further standardize commit messages, you might add rules for scopes. For example:module.exports = { // …existing settings… rules: { + "scope-case": [2, "always", "lower-case"], + "scope-empty": [2, "never"], // …existing rules… } };This enforces lowercase scopes and disallows empty scopes, which helps maintain uniformity when using
type(scope): subject.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/commit-lint.yml(1 hunks).gitignore(1 hunks).husky/commit-msg(1 hunks)README.md(3 hunks)commitlint.config.js(1 hunks)package.json(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/commit-lint.yml
8-8: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
11-11: the runner of "actions/setup-node@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 YAMLlint (1.35.1)
.github/workflows/commit-lint.yml
[error] 18-18: no new line character at the end of file
(new-line-at-end-of-file)
🪛 markdownlint-cli2 (0.17.2)
README.md
47-47: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
90-90: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
96-96: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
123-123: Multiple headings with the same content
null
(MD024, no-duplicate-heading)
🪛 LanguageTool
README.md
[uncategorized] ~88-~88: The official spelling of this programming framework is “Node.js”.
Context: ...d npm** - Download and install from nodejs.org - Verify i...
(NODE_JS)
[grammar] ~112-~112: “Bug” is a singular noun. It appears that the verb form is incorrect.
Context: ... - feat: A new feature - fix: A bug fix - docs: Documentation changes - `styl...
(PCT_SINGULAR_NOUN_PLURAL_VERB_AGREEMENT)
[uncategorized] ~115-~115: Loose punctuation mark.
Context: ... changes (formatting, etc.) - refactor: Code changes that neither fix bugs nor ...
(UNLIKELY_OPENING_PUNCTUATION)
🔇 Additional comments (7)
package.json (2)
1-22:commitlint.config.jsmissing from review.Your scripts and workflows reference
commitlint.config.js, but it wasn’t included here. Please ensure the file exists at the repo root so that commitlint can enforce your conventional commit rules as intended.
1-22:package.jsonsetup looks solid.Dev dependencies, scripts (
prepare,commit), and the Commitizen adapter configuration are correctly defined and should enable seamless commit message linting and generation.commitlint.config.js (5)
1-3: Extend Conventional Commit Rules
Good use ofextends: ["@commitlint/config-conventional"]to inherit the widely-adopted conventional commit rule set. This minimizes duplication and guarantees consistency with the standard.
4-8: Review Line Length Constraints
You’ve set the body and footer to an error at 100 characters, and the header max‐length to 100 as well. The Conventional Commits spec (and many teams) recommend a header limit of 50–72 characters for readability in terminals and changelogs. Please verify if 100 is intentional for your workflow; if not, consider reducing"header-max-length": [2, "always", 72]to align with best practices.
9-13: Enforce Subject Casing
Thesubject-caserule disallows sentence-case, start-case, pascal-case, and upper-case, effectively enforcing lowercase (or kebab–case) without being overly prescriptive. This aligns well with common conventions.
14-15: Prevent Empty Subjects and Trailing Periods
Thesubject-emptyandsubject-full-stoprules correctly enforce a non-empty subject and forbid trailing periods, which improves clarity and cleanliness of the commit header.
16-24: Restrict Commit Types to Approved Categories
Your configuration fortype-case,type-empty, andtype-enumproperly enforces lowercase, non-empty types and limits them to the agreed-upon set (build,chore,ci,docs,feat,fix,perf,refactor,revert,style,test). This ensures consistency and prevents ad-hoc types.
|
1 participant
📋 Description
Fixes : PSMRI/AMRIT#85
This PR introduces commit message standardization for the TM-API project by setting up Commitlint, Husky, and Commitizen. The goal is to enforce a consistent commit message format across the repository to improve collaboration, readability, and enable automation (like changelogs and versioning) in the future.
These tools are now fully integrated:
Commitlint enforces conventional commit message structure
Husky prevents non-compliant commits by using Git hooks
Commitizen provides an easy, interactive CLI for making properly formatted commits
GitHub Actions validate commit messages for all pull requests
✅ Type of Change
ℹ️ Additional Information
Added Configuration Files
commitlint.config.js - Defines commit message validation rules
.husky/commit-msg - Hook that runs validation on commit messages
.github/workflows/commitlint.yml - GitHub Actions workflow for PR validation
Dependencies Added
@commitlint/cli and @commitlint/config-conventional - For commit message linting
commitizen and cz-conventional-changelog - For guided commit creation
Added commit script for easy Commitizen access
Configured Commitizen adapter settings
Ensured compatibility with existing scripts
Testing Completed
Successfully blocked malformed commit messages locally
Generated proper commits using the new tooling
Verified GitHub Actions correctly validate PR commits
Ensured compatibility with existing development workflows
Changes overview
Commitlint functionality working properly:
Commitzen working:
Summary by CodeRabbit