search

googleapis / release-please

generate release PRs based on the conventionalcommits.org spec
https://www.conventionalcommits.org
Apache License 2.0
4.64k stars 350 forks source link

Jira integration and release-please results in "No user facing commits found" #2047

Open jdinsel-xealth opened 1 year ago

jdinsel-xealth commented 1 year ago

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. 

commit 1234567890abcdef
Author: Me
Date: ...

   JIRA-1234: Adds a new feature that does interesting things

   * fix: fixes a bug with the ...

   * feat: Adds the new XYZ feature

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

jtcressy commented 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.

hn-seoai commented 10 months ago

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.