CLI option to check and fix incorrect commit messages

[Rizhiy]

CLI option to check and fix incorrect commit messages

[codejedi365]

Add extra options to check commit message style and also to fix incorrect messages.

Thank you for your input! I can understand why you would want something like this. I have faced and solved similar problems like this for teams. Luckily, It is a solved problem.

I would like to add an action to CI to check that all commits since last version are in correct style, so I can check that MR won't break versioning.

If you are using angular, I highly recommend looking into the GitHub App Conventional Commits as one way to enforce commit standards. My personal recommendation is to use commitizen (there is a JS and Python variant, but I am talking about commitizen.py here). Not only does it provide an interactive cli for making messages (add it as a commit hook) but it can be called with the check option and it will validate a range of commits. I personally use the check options for checking any PRs from the CI to prevent invalid messages from getting into the repo. I also use it as a git commit-msg hook to enforce upon commit.

If you are using another parser type or a custom one, please let me know. I'm not sure if there are already built validators out there.

Also, I would like to be able to fix incorrect commits locally, probably by using rebase+reword functionality.

This is a very complicated problem within git as it must rebuild streams of commits. I have scripted something like this before and it is non-trivial. for that reason, I think is outside of the scope of Semantic Release.

Generally, PSR focuses on interpreting versions based on standards and creating releases. This type of requirement would be a pivot towards enforcing or fixing standards.

I recommend putting in safeguards via CI verification on PRs for commit linting, and also at the local git hook level. This prevents poorly styled commits into the repo. The one hole is the Web IDE, and direct pushes to main (trunk based dev) but those are organizational management items. These components should solve most of the issue in my opinion as it has for my teams. Let me know what you think.

One other component you could consider is using the following command to provide a bit of a check on version determination. This command will throw a non-zero exit code if a version is not going to be released.

semantic-release version --print --strict

Ultimately, I think other tools handle solving this problem already and seems kinda duplicative to add this additional functionality. I say this because our two tools already complement each other as we implement the same conventional commit standard.