Skip to content

Conversation

@ynancher
Copy link

@ynancher ynancher commented Dec 9, 2025

Adds the commit-msg-check GitHub Action
Checks commit messages added in pull requests
Valid for any PRs raised on this repository
Enforces these checks:

Commit Subject: Must exist and be ≤ 50 characters
Commit Body: Each line must wrap at 72 characters
Blank Line Check: Ensures a blank line between subject and body Also checks for blank line before Signed-off-by

Adds the commit-msg-check GitHub Action
Checks commit messages added in pull requests
Valid for any PRs raised on this repository
Enforces these checks:

Commit Subject: Must exist and be ≤ 50 characters
Commit Body: Each line must wrap at 72 characters
Blank Line Check: Ensures a blank line between subject and body
Also checks for blank line before Signed-off-by

Signed-off-by: Yashasvi Nancherla <[email protected]>
@koenkooi
Copy link
Contributor

koenkooi commented Dec 9, 2025

Can we enforce having a colon ':' in the subject as well? Related to that, the commit message of this PR should be something like:

`github workflows: add commit message checker

This workflow checks commit messages added in pull requests, valid for any PRs raised on this repository.

It enforces these checks:

  • DCO
  • Commit Subject: Must exist and be ≤ 50 characters
  • Commit Body: Each line must wrap at 72 characters
  • Blank Line Check: Ensures a blank line between subject and body
  • Checks for blank line before Signed-off-by

Signed-off-by: Yashasvi Nancherla [email protected]`

@ricardosalveti
Copy link
Contributor

ricardosalveti commented Dec 9, 2025

This check won't really be enforced, as we have multiple valid cases which are containing larger lines in both subject and body, so wonder if we should really enable it here.

DCO is already verified by its own check, so the only extra we could enforce is the blank line check.

@lumag
Copy link
Contributor

lumag commented Dec 9, 2025

NAK from my side. It was asked if we want this kind of checks and my answer didn't change: overriding these checks (when it makes sense, e.g. when the message includes logs) brings much more troubles than we benefit from these checks.

@github-actions
Copy link

github-actions bot commented Dec 9, 2025

Test run workflow

Test jobs for commit d727b4d

@test-reporting-app
Copy link

Test Results

 14 files  ± 0   26 suites   - 2   51m 49s ⏱️ + 16m 11s
 54 tests + 4   48 ✅  -  2  0 💤 ±0  6 ❌ +6 
294 runs   - 10  287 ✅  - 17  0 💤 ±0  7 ❌ +7 

For more details on these failures, see this check.

Results for commit d727b4d. ± Comparison against base commit 65bdc36.

@ynancher
Copy link
Author

ynancher commented Dec 9, 2025

This check won't really be enforced, as we have multiple valid cases which are containing larger lines in both subject and body, so wonder if we should really enable it here.

DCO is already verified by its own check, so the only extra we could enforce is the blank line check.

Hi @ricardosalveti and @lumag , As you rightly mentioned, DCO is verified by its own dedicated check. The subject and body length limits and the check-blank-line toggle to true or false are fully customizable and can be tailored for each tech team based on their requirements. The commonly used values—50 characters for the subject and 72 characters for body line wrapping—are standard open-source conventions. However, if your team prefers a larger character limit or if you want to set the check-blank-line to true or false, this action allows you to do that.

@lumag
Copy link
Contributor

lumag commented Dec 9, 2025

I prefer not to have written-in-stone limits and use common sense instead.

@ynancher
Copy link
Author

ynancher commented Dec 9, 2025

I prefer not to have written-in-stone limits and use common sense instead.

I see your point about not using strict limits. The reason we suggest having configurable checks is to maintain consistency across multiple contributors. While these checks are optional, they help ensure clarity and readability in commit history. If you’d prefer not to enable them, that’s completely fine. Thank you for your time!

@lumag lumag closed this Dec 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants