As part of my CI/CD pipeline workflow, I am considering to make use of conventional commits to auto-generate release drafts in github. The idea of creating draft is to allow the code owners to review release notes before publishing it.
However, I am worried if this could cause following two issues:
- If we go ahead and create each commit message as conventional commit we would end up with a huge log of changes as disconnected information in release drafts which would need to be manually refactored to make any sense out of it before being published
- Alternative approach, I could think of is to refrain committing changes until all related changes are completed and when done push all related changes under a single commit message. However, this goes against the proposition of CI/CD as it would delay early merges
As a solution to the aforementioned issues, I was thinking of making use of conventional commits only when I create pull-requests to the mainline by the end of completion of a feature. This way I could avoid all the noise in the release draft and yet automate creation of release notes. But I am not very sure if this is the right approach. I would like to know what strategy others are employing to deal with this issue and if the approach I am planning to take is right? Or if we are better off creating release notes manually? Thanks!