Valid conventional commits treated as invalid

[lersveen]

Commit linting is configured to throw an error when commit subject has subject uses sentence-case, start-case, pascal-case or upper-case. It's nice to be consistent, but e.g. chore: Remove old host vmalxsift01 (sentence-case) should be perfectly valid.

The official conventional commits specification does not mention case of subject. Treating valid conventional commits as errors makes no sense.

Example of failing commit lint: https://github.com/nrkno/linuxadmin-saltstack/pull/2863#issuecomment-2196705327

I made a PR with suggested solution in Saltstack, but it's better implemented upstream in this workflow.

Also, see the in-depth discussion about this issue in the commitlint repo: conventional-changelog/commitlint#2141

[martinsolberg]

The commit lint implementation is derived from the Angular contribution format. Personally I prefer it. It maintains visual consistency and grep-ability in the shell (without adding -i).

[lersveen]

The commit lint implementation is derived from the Angular contribution format. Personally I prefer it. It maintains visual consistency and grep-ability in the shell (without adding -i).

It's not. The workflow default config uses the shared config @commitlint/config-conventional documented as a "shareable commitlint config enforcing conventional commits" and does not reference Angular. There is a separate shared config called @commitlint/config-angular.

The biggest issue right now is that there is no explicit documentation on any level of what actual behaviour to expect. Consistency is nice, but it seems counter-productive to enforce a default that is stricter than (and could be considered a faulty implementation of) the conventional commits specification.

[github-actions]

🎉 This issue has been resolved in version 3.1.0 🎉

The release is available on:

• GitHub release
• v3.1.0

Your semantic-release bot 📦🚀