Enforcing semantic commit messages

[kewisch]

We recently agreed in the git commit guide we'd use semantic commits. I'd like us to enforce this automatically as much as possible. Proposed actions:

• Adjust dependabot config to use chore(deps): as a prefix
• Change merge setting "Default commit message" to either "Pull request title" or "Pull request title and description", and add a GitHub action to enforce the pull request title needs to be semantic as well.
• Add a GitHub action and local checks that enforces that each commit uses semantic commits (e.g. commitlint)

@wmontwe @toddheasley does this make sense? Should we add the same checks for iOS as well?

[kewisch]

Related issue to consider re the git commit guide:

What is our catalog of scope tags? The git commit guide mentions a few in a table, but then doesn't consistently use them in the examples (e.g. ci vs build). Do we just make them up as we go, or do we use predefined categories?

[kewisch]

I've done some light research, it doesn't feel like there is a perfect fit for commit message linting in our ecosystem:

1. commitlintjs works very well, but we don't have a node project so this would be a new package.json and yet another tool ecosystem
2. There seems to be a python commitlint, but same problem we don't really have a python project
3. It doesn't appear detekt/spotless or the other lint tool support commit linting
4. We could do a custom github action that checks via regex or runs commitlint without installing it, but this way developers can't really validate commit messages until they do the pull request.
5. We could do a custom shell script that can be run from the github action, but then we have to maintain/improve it ourselves.

Did I miss any solutions in the gradle world?

[wmontwe]

@kewisch there is a Gradle Plugin: https://github.com/nicolasfara/conventional-commits

But didn't test it yet and usage is quite low.

[toddheasley]

For shared process like this, it makes sense to me to be consistent across Android and iOS. I don't have any experience with the problem(s) this solves; can't really weigh in on that. Defer to your judgment here.

[kewisch]

We discussed this today, we're going to aim for either a gradle based solution or a custom no-dependencies python script. This way we avoid buying in to yet another ecosystem.