This PR adds the Github Actions https://github.com/amannn/action-semantic-pull-request and https://github.com/wagoid/commitlint-github-action to check that both the commit messages and the title of a pull request adhere to the conventional commits standard. The title is also checked because we will encourage squash commits for small PRs and PRs that rewrite the same files over and over, and Github will suggest the PR title as squash commit message by default, ensuring that the entire history adheres to the conventional commits spec.
We may want to separate the check-commits job into its own workflow to also run on the push event because someone could technically modify the commit message on merge (or rebase if manual), but this would require allowing someone to force-push the corrected message anyway. I think we should see if people abuse the mechanism in which case we will change the workflows accordingly, otherwise it's probably not worth the hassle.
In the future, we may want to implement our custom Github actions, for instance if we want to standardize the tool or the config (e.g. commitlint), or if we want to perform additional actions such as commenting on the PR for instance.
Closes #13
This PR adds the Github Actions https://github.com/amannn/action-semantic-pull-request and https://github.com/wagoid/commitlint-github-action to check that both the commit messages and the title of a pull request adhere to the conventional commits standard. The title is also checked because we will encourage squash commits for small PRs and PRs that rewrite the same files over and over, and Github will suggest the PR title as squash commit message by default, ensuring that the entire history adheres to the conventional commits spec.
We may want to separate the
check-commitsjob into its own workflow to also run on thepushevent because someone could technically modify the commit message on merge (or rebase if manual), but this would require allowing someone to force-push the corrected message anyway. I think we should see if people abuse the mechanism in which case we will change the workflows accordingly, otherwise it's probably not worth the hassle.In the future, we may want to implement our custom Github actions, for instance if we want to standardize the tool or the config (e.g. commitlint), or if we want to perform additional actions such as commenting on the PR for instance.
You can see an example run in https://github.com/clicepfl/clic-website-v2/pull/9