Add automatic check for commit message format by shamitha-shashidhara · Pull Request #36 · eclipse-openbsw/openbsw

shamitha-shashidhara · 2024-12-06T12:42:18Z

Add GitHub Actions workflow to commit messages on push and pull request events.
Create custom configuration file (.commitlintrc.json) to enforce commit message standards.
Document commit message format in CONTRIBUTING.md

aschaal · 2025-09-30T11:25:37Z

.commitlintrc.json

+      "header-trim": [2, "always"],
+      "subject-empty": [1, "never"],
+      "subject-full-stop": [2, "never", "."],
+      "subject-max-length": [1, "always", 50],


50 chars will lead to cryptic subject lines, I strongly vote for 72 chars like in the body.

I have updated it to 72 chars.

aschaal · 2025-09-30T11:26:49Z

.commitlintrc.json

+      "body-leading-blank": [2, "always"],
+      "body-max-line-length": [1, "always", 72],
+      "body-case": [1, "always", "sentence-case"],
+      "signed-off-by": [1, "always", "Signed-off-by:"]


I don't like this very much. Let's discuss this in the public OpenBSW round.

aschaal · 2025-09-30T12:18:59Z

.commitlintrc.json

+      "revert",
+      "style",
+      "test"
+    ]],


The terms are overlapping, e.g. what to use when refactor the code which improves performance? What if you fix the doc? What would you do when working on process descriptions, is that doc? What would you choose when removing a function? Is that refactor?

Personally, I would not limit this to a certain set of term, but recommend some terms, e.g. start of "Revert" if you revert a comment.

Btw, starting a commit message with lower case looks strange to my eyes.

The tool is designed to include a type in the commit message header. However, based on your suggestion, users are free to use any custom type; this will only generate a warning, not an error. Similarly, if a commit message does not include a type at all, it will still generate a warning, not an error.

I have also updated the commit message to start with an uppercase letter.

Additionally, we can remove the type restriction from the JSON configuration file to allow contributors more flexibility but the tool will continue to function as designed, issuing a warning if the type is missing, not error

aschaal · 2025-09-30T12:24:20Z

CONTRIBUTING.md

 4. Push to the Branch (`git push origin newBranchName`)
 5. Open a Pull Request

+### Commit Message Format


Imho this should be moved to the Sphinx guideline (GitHub pages) and only link from here to the guideline to avoid building up a "second source".

CONTRIBUTION should only summarize what is needed to contribute.

The detailed commit message guidelines have been moved to the Sphinx documentation (GitHub Pages).
The CONTRIBUTING.md now contains a link to the full guidelines in the documentation.

aschaal · 2025-09-30T12:25:27Z

CONTRIBUTING.md

+* **revert**: To undo previous commits
+* **style**: Changes related to formatting or whitespace adjustments
+
+##### Subject line


Use always "Title Case": https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case

Done for several other headings already in this file.

Acknowledged

aschaal · 2025-09-30T12:25:40Z

CONTRIBUTING.md

+
+##### Subject line
+
+Use the subject field to provide a breif description of the change:


Typo: breif

Acknowledged

- Add GitHub Actions workflow to lint commit messages on push and pull request events. - Create custom commitlint configuration file (.commitlintrc.json) to enforce commit message standards. - Document commit message format in CONTRIBUTING.md Signed-off-by: Shamitha Shashidhara <shamitha.shashidhara@accenture.com>

johannes-esr · 2025-10-07T08:33:25Z

Would it make sense to use gitlint like in S-CORE?

christian-schilling · 2025-10-28T09:47:00Z

doc/learning/commitmessage/index.rst

+
+.. code-block:: text
+
+    <type>: <subject line>


We probably don't want any additional metadata like in the subject line. So this particular check would need to be reversed.

shamitha-shashidhara marked this pull request as draft December 24, 2024 09:48

shamitha-shashidhara force-pushed the formatcheck branch 3 times, most recently from 26f2941 to f384393 Compare December 30, 2024 05:12

shamitha-shashidhara marked this pull request as ready for review January 8, 2025 05:14

shamitha-shashidhara force-pushed the formatcheck branch from f384393 to d34853c Compare January 15, 2025 13:10

shamitha-shashidhara force-pushed the formatcheck branch from d34853c to e01a6d6 Compare May 26, 2025 09:39

aschaal reviewed Sep 30, 2025

View reviewed changes

shamitha-shashidhara force-pushed the formatcheck branch from e01a6d6 to 8cf7d79 Compare October 3, 2025 07:21

christian-schilling requested changes Oct 28, 2025

View reviewed changes

shamitha-shashidhara closed this Nov 13, 2025


		##### Subject line

		Use the subject field to provide a breif description of the change:

Conversation

shamitha-shashidhara commented Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shamitha-shashidhara Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johannes-esr commented Oct 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

shamitha-shashidhara commented Dec 6, 2024 •

edited

Loading

shamitha-shashidhara Oct 3, 2025 •

edited

Loading