Enforce conventional commits

[ctron]

This is maybe more a cross-organization issue, but I'll add it here anyway.

The idea is to enforce the use of conventional commits, using a GitHub actions. The rationale behind it is:

• We want to create meaningful and complete (as possible) release notes. We already have an automated setup for this, we only need more data. This would require us at least to think into this direction
• Conventional commits is a way others use well, so there's tooling around that
• We want to communicate with QE what changed during a release. It's hard to deduct that from the issues, as it's not clear what issue is part of which release. This would help.

This would mean:

• We use conventional commits for all commits, and for all repositories
• We try to be meaningful authoring those commits, and check this during PR reviews
• We reference issues which we close in those commit messages, which helps with GitHub automation too
• We do this on all repositories which become part of the release (Main, UI, Helm Charts, Ansible Playbook, Operator, …)

[jcrossley3]

I try to be careful to prefix fixes and new features with "fix:" and "feat:", and occasionally I'll use "refactor:" to denote that no behavior should've changed.

But I kinda hate the "chore:" prefix. I think it's pedantic, redundant and a waste of valuable first-line message space.

I would prefer we not require some sort of prefix on every commit. As long as the tooling ignores un-prefixed commit messages, I think this is fine.

[ctron]

I would prefer we not require some sort of prefix on every commit. As long as the tooling ignores un-prefixed commit messages, I think this is fine.

That kind of defies the purpose of this. As that's the state we have right now and I'd say it doesn't work.

[jcrossley3]

Let's start by requiring folks to use "fix:" or "feat:" for at least one of the commits in any given PR that is either fixing something or introducing a new feature.

If the tooling creating the release notes only looks for those prefixes, I think that will achieve the purpose of this.

[ctron]

Yes, that's what we have today. I'd say it doesn't work.

But let's give it another try. If it continues to not work, we just need to find a way.

[i386x]

I am +1 for this. How we to enforce this? Is there any GitHub action and/or precommit hook to check the syntax/format of commit messages? Yes, it is.

[ctron]

I am +1 for this. How we to enforce this? Is there any GitHub action and/or precommit hook to check the syntax/format of commit messages?

Yes, there are few. I've been using this one in the past: https://github.com/webiny/action-conventional-commits … But I guess there are other options. It's not uncommon.

[JimFuller-RedHat]

I am +1 to adopt (with the caveat that I am probably the person who is most likely to forget doing it!)

[chirino]

+1 if we can enforce /w automated PR check. I hope a failure message will link folks to a page showing what the commit message should look like.

[helio-frota]

I am +1 to adopt (with the caveat that I am probably the person who is most likely to forget doing it!)

depending on how you commit it may help:

https://gist.github.com/RangHo/17fc8ea229faeea97e4e1c4c16439f3d

save to a file called .gitmessage in home dir and then git config --global commit.template ~/.gitmessage

[ctron]

Maybe we can all 👍 or 👎 on the initial comment, so that we have a poll.