-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exit with error when dry run does not trigger new release #3075
Comments
The tool you're looking for is You'll also find a guide to setup checking PR commits in GitHub Actions here: https://commitlint.js.org/#/guides-ci-setup?id=github-actions Your second request about specifying a specific number of compliant commits seems odd, but you can probably implement such a thing using |
@sheerlox Thanks, do you think The usefulness for a specific number of commits serves a common use case, where, if you're building an application, you might require, that there would be only one commit/ per PR/ per release, before a PR merge. Therefore it would be handy if while checking commit label for compliance, you'd also allow only one. I don't exactly remember how semantic-release behaves, when for example it encounters two 'feat' commits, but I guess it would still make 1 release, but with two features mentioned in the changelog. Coming back to commitlint, it might be good enough, but the dry-run, checks a few things more then just commit labels, and it would be an advantage to be able to use it in a CI job. |
Both parsers are based on the same standard convention (Conventional Commits), so as long as the same preset is used, they should always be in sync. However
That's definitely out-of-scope for
Correct. |
New feature motivation
I'd like for my github action to fail, if PR is raised and new commits do not adhere to required format that could trigger a new release.
Aside of this, it would be an advantage to be able to define number of compliant commits expected, so it would fail if you require 1 compatible commit, and you encounter 0,2,3 and so on.
New feature description
Aside of this, it would be an advantage to be able to define number of compliant commits expected, so it would fail if you require 1 compatible commit, and you encounter 0,2,3 and so on.
New feature implementation
Currently I have to resort to this:
Exit code of above job is always a success (regardless if commit label was correct or not).
It would be sufficient if there was a commit analyzer somwhere, which without specifying any extra configs, could with 100% compatibility with semantic-release expectation evaluate a commit label. Please let me know if a tool such as this exists.
The text was updated successfully, but these errors were encountered: