⚠️ THIS SERVICE IS NO LONGER MAINTAINED ⚠️
I maintained this project and kept the webservice running for several years, but it was often difficult, time-consuming, and generally low on my priority list compared to other things like work and family. The final blow was a Heroku incident in April 2022 in which all of Heroku's GitHub-related secrets were compromised, and Heroku invalidated existing secrets and disabled support for all GitHub-related integrations.
If you're looking for an alternative way of semantically checking your PRs, see the Alternatives section in the README below. GitHub Actions are the way to go!
Thanks for your understanding. I wish you luck on your journey to semantic englightenment.
Semantic Pull Requests
GitHub status check that ensures your pull requests follow the Conventional Commits spec
How it works
By default, only the PR title OR at least one commit message needs to have semantic prefix. If you wish to change this behavior, see configuration section below.
|Scenario||Status||Status Check Message|
|PR title is semantic||
|any commit is semantic||
|nothing is semantic||
Take this PR for example. None of the commit messages are semantic, nor is the PR title, so the status remains yellow:
Edit the PR title by adding a semantic prefix like
feat: or any other
conventional commit type. Now use
Squash and Merge to squash the branch onto master and write a standardized commit message while doing so:
By default, no configuration is necessary.
If you wish to override some
behaviors, you can add a
semantic.yml file to your
.github directory with
the following optional settings:
# Disable validation, and skip status check creation enabled: false
# Always validate the PR title, and ignore the commits titleOnly: true
# Always validate all commits, and ignore the PR title commitsOnly: true
# Always validate the PR title AND all the commits titleAndCommits: true
# Require at least one commit to be valid # this is only relevant when using commitsOnly: true or titleAndCommits: true, # which validate all commits by default anyCommit: true
# You can define a list of valid scopes scopes: - scope1 - scope2 ...
# By default types specified in commitizen/conventional-commit-types is used. # See: https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json # You can override the valid types types: - feat - fix - docs - style - refactor - perf - test - build - ci - chore - revert
# Allow use of Merge commits (eg on github: "Merge branch 'master' into feature/ride-unicorns") # this is only relevant when using commitsOnly: true (or titleAndCommits: true) allowMergeCommits: true
# Allow use of Revert commits (eg on github: "Revert "feat: ride unicorns"") # this is only relevant when using commitsOnly: true (or titleAndCommits: true) allowRevertCommits: true
This project is a GitHub App that you can install on one or many repositories, making it a convenient choice if you want to use it on lots of different repos, or even an entire GitHub organization full of repos.
If, however, you want more control over exactly how and when your pull requests are semantically checked, consider writing your own custom Actions workflow using a GitHub Action like amannn/action-semantic-pull-request.
See also https://github.com/squash-commit-app/squash-commit-app, a GitHub App which adds an empty commit to an open pull request with a single commit when the title was changed