search

zmkfirmware / zmk

ZMK Firmware Repository
https://zmk.dev/
MIT License
2.82k stars 2.85k forks source link

CI: Add enforcement of conventional commit messages for PRs #2618

Closed petejohanson closed 1 week ago

petejohanson commented 2 weeks ago

In order to effectively leverage release-please for release automation, we need to actually enforce the use of conventional commits for our PR/commits, so that release-please can do a proper job of generating changelogs, determining next release version number, etc.

Probably takes the form of an additional GH Action to check commit messages for PRs.

Nick-Munnich commented 2 weeks ago

It might be nice to, on test failure, have a message informing/reminding contributors about the details of conventional commits, along with listing helpful commands to rename and squash their commits accordingly.

caksoylar commented 2 weeks ago

We should start by documenting this more specifically, maybe in a new page under "Development -> Contributing". By specifics I mean e.g. it'd be nice if we can enumerate possible categories as it relates to ZMK. E.g. "use docs: only for all docs PRs", use feat(boards): for new boards, use chore: for npm updates, etc.

https://github.com/zmkfirmware/zmk/blob/main/CONTRIBUTING.md already mentions conventional commits, but I am not sure if people check there and I haven't been trying to update it either. I am not sure if we should document there also, or move its contents to docs and update it to simply tell people to check the "Contributing" section.

caksoylar commented 2 weeks ago

As a side note, wouldn't automating checking certain commit types be a bit difficult? Like being able to tell what is a breaking change, when both types of files (say docs+boards) are touched in a PR, etc.

petejohanson commented 2 weeks ago

As a side note, wouldn't automating checking certain commit types be a bit difficult? Like being able to tell what is a breaking change, when both types of files (say docs+boards) are touched in a PR, etc.

I think at best this should be checking the format, not whether the selected type/area is correct. That will still require human verification, IHMO.

petejohanson commented 2 weeks ago

Looking like gitlint is a nice option for this: https://jorisroovers.com/gitlint/latest/

Nick-Munnich commented 1 week ago

Closed by #2623