search

nrkno / github-workflow-semantic-release

Semantic Release workflow through github action
4 stars 0 forks source link

Valid conventional commits treated as invalid #131

Open lersveen opened 2 days ago

lersveen commented 2 days ago

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: https://github.com/conventional-changelog/commitlint/issues/2141

martinsolberg commented 2 days ago

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 commented 2 days ago

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 actualy 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.