|
jbauer opened 10 months ago
|
||||
|
This will be addressed via #1461, which improves the conventional commit message check to validate commit message footer |
||||
|
|
Robin Shen changed state to 'Closed' 10 months ago
|
||||
|
|
With build #3892 it is now possible to check commit message footer in branch protection rule when conventional commit is enabled |
||||
|
|
Hmm ok, will take a look at it. But I can not relate the check to a commit type, e.g. |
||||
|
|
Yes you can configure applicable commit types for the footer check. Agree that auto-closing pull requests when some build passes also has its value and deserves a different feature request. |
||||
|
|
Also enabling branch protection does not mean that a commit has to be submit via pull request. As long as the commit satisfies branch proection criterias, it will be accepted via push without pull request. |
| Type |
Improvement
|
| Priority |
Normal
|
| Assignee |
It is relatively specific, so not sure if you are interested in such an improvement:
If you use conventional commits you could generate a changelog automatically by parsing commit messages. However if the changelog is for non technical people (e.g. customers) and possibly bundled with the built app you need to make sure that developers write commit messages that can also be understood by non technical people or that commit messages have a defined conventional commit footer that contains text specifically for the changelog target audience.
Because it is difficult to rename commits once they have been pushed/pulled and new commits are on top it would be nice to configure OneDev to force pull requests for specific conventional commit types. So you could configure at branch protection level that it should only protect the branch for e.g.
featureandfixcommits since both would end up in a changelog. That way the commit message can be reviewed as part of the pull requests or the person who merges the pull request can write the proper commit message (in case you squash original commits).An alternative would be a custom regex but as you already experienced it is relatively complex to define a regex that matches against the conventional commit spec in a very detailed way. So reviewing the commit message before committing sounds like the better approach.