jbauer
opened 3 years ago
-
This will be addressed via #1461, which improves the conventional commit message check to validate commit message footer
-
Previous Value Current Value Open
Closed
-
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.
fixorfeature? Reasoning is that we don't want to make pull requests for everything as it would be too much burden for a smaller team. But some important things we want to do via pull requests just to be sure. Might be a different story if OneDev could auto-accept/merge pull requests as long as a CI build has run successfully. -
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.