Strategies for enforcing commitizen

[LinusU]

I'm not sure that this is the right place to open this but here goes; have there been any discussions on how to enforce commitizen? We started using it in a few projects at work but it's both easy to forget and hard to make sure that everyone committing to the project respects it.

Maybe an idea would be to add a commitizen check master that checks all commits that have been added on this branch when compared to master. The exit code should be 0 (success) when all messages looks good.

This way we can run that as part of our CI step.

Any ideas?

[jimthedev]

I agree that exit codes need to be fixed.

One thing you can do to enforce this on your CI is set up this:

https://github.com/kentcdodds/validate-commit-msg

[jimthedev]

Also, from a purely ideological standpoint. Commitizen is a purely opt in tool since not doing so would harm those that are capable of following the convention without this tool. For those people, forcing a tool on them is inadvisable. With that said, if you're in a situation where you need to ensure that people are following the convention, then validate-commit-msg should be used with commitizen. It makes sure that the conventions are being followed. I'd love to see someone from the community find a way to make validate-commit-msg have adapters in the same way that commitizen has adapters since not everyone uses the conventional changelog. For example, some people use Jira smart commits, and they probably still would like to be able to validate their commit messages.

I'd be open to hearing alternative solutions to the problem as well.

Thanks!

Jim

[jimthedev]

Hi @LinusU. Were you able to figure out enforcement of commit conventions?

[LinusU]

Not yet, but I'm thinking something towards having a small script check the log running on Travis or similar...

[marionebl]

Could this be adressed by a See also section in readme.md like e.g conventional-changelog/conventional-changelog?

[LinusU]

That could be a good idea 👍

The way I ended up solving it was to let my adapter have a "bin" field in the package.json that exposed a small verify command. Since it's already included in my devDependencies it was easy to add it to my test script.

e.g.

{
  "scripts": {
    "test": "mocha && cz-linusu verify HEAD..master"
  },
  "devDependencies": {
    "cz-linusu": "^0.1.0"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-linusu"
    }
  }
}

[shogochiai]

My strategy is like this.

It prevents git commit locally, but don't kill git-cz.

"scripts": {
    "warn-commit": "echo '\n\n\n\n Use `yarn commit` \n\n\n\n' && exit 1",
    "commit": "npx git-cz --no-verify"
}, 
"pre-commit": [
    "warn-commit"
]

[PrasoonDavid]

Use Husky to overide standard git commit

"hooks": {
    "pre-commit": "lint-staged",
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
    "prepare-commit-msg": "exec < /dev/tty && git cz --hook || true"
  }