strict require_conventional

[MeitarR]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

We want to be able to check if our commits are valid conventional and also verify that their type is recognized (one of a predetermined list)

Desired solution

I'm not sure if this is the best solution, but maybe add a list of require_conventional_commit_types to the config that only when it has values and require_conventional is true, then it will also verify that the commit types are one from the list.

Alternatives considered

Check it with another tool instead

Additional context

No response

[orhun]

Hello, thanks for reporting/idea!

How about something like this instead:

[git]
commit_parsers = [
  { message = "test", required = true }
]

So the changelog generation will fail if nothing is matched. This will also work with unconventional commits if configured.

WDYT?

[MeitarR]

If I get it right, this means that if you don't use all the parsers, then it will fail which is bad for me.

More context about the reason I want this feature:
We have for most of our repos a CI job that runs for every MR and comment (and updates the message every time) with how this MR will affect the change log (using git-cliff, of course). So I want to also verify that all the commits added in the MR are valid (and if not, then fail the CI)

To continue with your idea, maybe we can add a new property fail_on_unmatched_commit that will have the same condition filter_commits, just instead of filtering out, it will fail

[orhun]

If I get it right, this means that if you don't use all the parsers, then it will fail which is bad for me.

Not really, it will only fail if required is true for an individual parser and if it's not being used.

But yeah, I see what you mean. It will also fail if the parser isn't matched because you don't have a specific commit type in your release.

Hmm, actually, isn't that what you want? 🤔

To continue with your idea, maybe we can add a new property fail_on_unmatched_commit that will have the same condition filter_commits, just instead of filtering out, it will fail

Do you mean this as a part of the commit_parsers?

[MeitarR]

If I get it right, this means that if you don't use all the parsers, then it will fail which is bad for me.

Not really, it will only fail if required is true for an individual parser and if it's not being used.

But yeah, I see what you mean. It will also fail if the parser isn't matched because you don't have a specific commit type in your release.

Hmm, actually, isn't that what you want? 🤔

Well, I know that I will have a fixed set of types. But for every MR it will probably not use all of the types so this leads me to the understanding that what I want is to fail if none of the commit_parsers matches

To continue with your idea, maybe we can add a new property fail_on_unmatched_commit that will have the same condition filter_commits, just instead of filtering out, it will fail

Do you mean this as a part of the commit_parsers?

I'm not sure what you mean by "as part of commit_parsers" but it's really the same as fillter_commits just fail instead of skip

[orhun]

Hmm yeah, I see what you mean.

I still like the idea of adding required option to commit_parsers. In your case, if you add it to each one then it will behave as the same as fail_on_unmatched_commit, right?

[MeitarR]

No, because then it will be required to make all the commit parsers match to generate the changelog (without handling the case where none of the commit parsers match for a single commit).

And what I need is to make sure that every commit matches any of the commit parses (its ok of some of the parses will never match)

[orhun]

Ah okay, I think I see it now. So in that case should we do fail_on_unmatched_commit or something like require_conventional_commit_types = ["feat", "fix", "chore", ...]?

[MeitarR]

Yeah, you got it right!

I think fail_on_unmatched_commit is the better solution here for 2 reasons

1. It will also support unconventional commits
2. You will need to specify your list of types once instead of twice

[orhun]

Got it. I think it makes sense then :)

Interested in doing a quick PoC?

[MeitarR]

Got it. I think it makes sense then :)

Interested in doing a quick PoC?

sure #1298