Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ci: add action to check for conventional commit messages (#281)
adhering to the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) format is vital to make our automatic release process with [release please](https://www.npmjs.com/package/release-please/v/11.14.2) work. - Automatically generating CHANGELOGs. - Automatically determining a semantic version bump (based on the types of commits landed). - Communicating the nature of changes to teammates, the public, and other stakeholders. - Triggering build and publish processes. - Making it easier for people to contribute to our projects, by allowing them to explore a more structured commit history. I will make this action a mandatory one. To follow the conventional commit format you only have to begin your commit message with: ```md <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` where `<type>` is one of: ```js [ "feat", "fix", "docs", "style", "refactor", "test", "build", "perf", "ci", "chore", "revert", "merge", "wip", ] ``` 1. fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning). 2. feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning). 3. BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. It is also possible to have multiple fixes and features in one commit message. Please consult the [conventional commits doc](https://www.conventionalcommits.org/en/v1.0.0/)
- Loading branch information