Open jdinsel-xealth opened 1 year ago
adding my 2 cents until we get a response from the maintainers on this issue:
What if you tried putting the jira issue key as a scope in the conventional commit? I know you get intermittent results with JIRA-1234: feat: something
but what if you did feat(JIRA-1234): something
? Most filtering implementations i've seen tend to be pretty permissive on scopes.
As @jtcressy said, put the Jira issue in the scope. We do it that way at our company, and it works perfectly fine. Automatic links from CHANGELOG.md to Jira works as well.
No user-facing commits are found when we title our pull requests with a reference to Jira even when the notes of the squashed merge contain conventional commits. Our policy requires us to add the jira issue identifier to the title of the pull request and this will link the GitHub pull request and jira automatically.
Example pattern: "JIRA-1234: Adds a new feature that does interesting things"
Within the commits in the pull request, we may have additional conventional commits defined.
Describe the solution you'd like
With some additional logging added to release-please, the CLI output shows that the merged pull requests are found and that the notes, like the example above, are seen, but the result remains that release-please reports "No user facing commits since ..." I believe this may be because the conventional commit filter removes the candidate based on the title of the pull request. However, each of the pull requests should be a likely candidate for the changelog and a release.
Describe alternatives you've considered
I have noticed that if the title includes a conventional commit tag after the jira identifier, that release-please will sometimes , but not always, generate a pull request. Example:
JIRA-1234: feat: Adds an awesome new feature