Strict mode: fail when commit does not match any rule about commit-analyzer HOT 5 CLOSED

Just spotted semantic-release/semantic-release#536 - I guess this is one way to solve it.

from commit-analyzer.

For using an external is the solution.
If it were to be implemented in semantic-release it would be as verifyRelease plugin.

semantic-release doesn't run on PR currently, for reasons explained in #585.

Throwing an error when there is no commits matching a rule is probably not a good idea, as running when no new commit has been added since the last release is a valid use case.

from commit-analyzer.

Duplicate of semantic-release/semantic-release#536

from commit-analyzer.

semantic-release doesn't run on PR currently, for reasons explained in #585.

Thanks, looks like I've got some reading to do, although in a non-public, non-Travis setup it might just work. Even with a missing token on Travis PR build, you could still in theory use semantic-release to validate commits - but I'll follow that up in #585 once I familiarize myself with things a bit more.

I agree there's some overlap with #536 and I did mention linting, but I do feel that "strict mode" might be a feature of its own. Let me reword a little bit...

Suppose you have commits since last release. Suppose none of these commits match a rule. semantic-release will silently not make a release. What I'm looking for is semantic-release instead warning me (by failing a build) that it's not going to make a release, because all commits that it found did not match any rules. This does mean that:

• if there were no new commits - all is good, no failure
• if there are only, say, docs commits - all is good, they match a rule, no failure
• there are commits, but all of them are untagged - failure; remediate by merging something that has a tag, so that there's an explicit "no release" or "release".

Failing when there's at least one untagged commit is probably a stretch and only useful at PR stage (i.e. lint), as the only way to solve that would be to force push into master, and that's probably a bad idea, so there'd need to be another way to avoid that dead end.

from commit-analyzer.

Validating commits (no matter the exact rules) is a lot more useful to do during the PR stage.
Once the commits are merged to master and semantic-release runs it's already too late. We could fail the release, but then there is no good solution for the user. Any new commit would trigger a release. The only way would be to rewrite commits on master which is not something we recommend.

This is why we don't fail on malformed commits. To avoid an inescapable situation.

The proper solution is to validate the commit format during the PR step, either with semantic-release once we have a good solution to run on PR builds or with an external tool.

from commit-analyzer.