[changelog] reference closed issues

[gotson]

Is your feature request related to a problem? Please describe.
I am evaluating jreleaser as a replacement for semantic-release for changelog generation. jreleaser doesn't mention the closed issues that are referenced in a conventional commit.

for example, the following commit message:

feat: add FileHeader.getFileName

which returns the Unicode filename if it exists, and the ASCII filename otherwise
the existing methods FileHeader.getFileNameString and FileHeader.getFileNameW are deprecated

closes #34, closes #53

produced the following release note: https://github.com/junrar/junrar/releases/tag/v7.2.0

Describe the solution you'd like
It would be nice if jreleaser could parse the references to issues within commit messages, and add them to the changelog.

In a conventional commit, an issue could be referenced in the footer, like shown above, or directly in the body, for example:

feat: a new feature

this continues the work done in #3 and lays the foundation for #5

Describe alternatives you've considered
other tools like semantic-release can do this

[aalmiray]

Good suggestion. As I understand it GitHub has a predefined set of keywords that may be used to interact with issues. I suppose GitLab and Gitea can do the same but it's likely the set of keywords is not identical, thus some Git service specific customization may be needed.

How would you like to see the rendered changelog? Given the sample commit message (title & body) you posted there will be 1 row marked as feature but then how should #3 and #5 be laid out? Also, titles and messages for both of these issues would have to be retrieved from the remote server (something JReleaser does not do, yet), with perhaps further processing as there may be other referenced issues.

[gotson]

Note that semantic-release doesn't parse the keywords specific to each git service.

For example, a commit with the message:

feat(rest api): ability to re-analyze a book
working towards https://github.com/gotson/komga/issues/51

would render in the changelog as :

* **rest api:** ability to re-analyze a book ([8e81356](https://github.com/gotson/komga/commit/8e81356908e42d1b7b8edb935a1eaf133cff7035)), closes [#51](https://github.com/gotson/komga/issues/51)

I don't think that's a big drawback, and probably saves a lot of hassle by not having to implement different set of keywords for each git service.

Given the sample commit message (title & body) you posted there will be 1 row marked as feature but then how should #3 and #5 be laid out? Also, titles and messages for both of these issues would have to be retrieved from the remote server (something JReleaser does not do, yet), with perhaps further processing as there may be other referenced issues.

I think something simple, without needing to retrieve the detail of the issue would work well. Just adding , closes #x with a reference to that issue would be sufficient i guess.

If a commit closes more than 1 issue (like this), the changelog can just mention each issue after , closes:

add FileHeader.getFileName ([b6da583](https://github.com/junrar/junrar/commit/b6da583ffbb861219fe20877fb78bf5092996914)), closes https://github.com/junrar/junrar/issues/34 https://github.com/junrar/junrar/issues/53

I also have an edge case where the commit mentions an issue from another repo. It could happen when you have multiple repos in an organization, or in this case where the project is forked and the original repo has been archived.

This commit has the message:

fix: inaccurate file times
thanks @tmyroadctfig

from https://github.com/edmund-wagner/junrar/pull/20

and is rendered as:

* inaccurate file times ([b1f9638](https://github.com/junrar/junrar/commit/b1f96385ff1738c1488b26968f71413f2a5085d4)), closes https://github.com/edmund-wagner/junrar/issues/20

[aalmiray]

I see. For the time being if the changelog is rendered on GitHub and the content has explicit links or mentions an issue by number then the GitHub renderer will automatically convert links and issue references, as seen at

https://github.com/jreleaser/jreleaser/releases/tag/v1.0.0-RC2

Where commits have the following titles and shas:

* 0cf4c03d (tag: v1.0.0-RC2) Releasing version 1.0.0-RC2
* b97e53b9 [deps] update aws-java-sdk to 1.12.191
* e8e1b8d1 [deps] update jsonschema to 4.24.1
* 51a27a8d [deps] update aws-java-sdk to 1.12.189
* 1ece52db [deps] update download gradle plugin to 5.0.4
* d5a5a877 [changelog] Refactor modifier replacement. Relates to #803
* 4ba4676e [changelog] try different line encodings when matching commit title/body. Fixes #804
* cce6050d [core] fix CalVer parsing when default version is requested. Fixes #803
* 610ece2f Bump for next development cycle

I believe GitLab and Gitea perform a similar feat. However, if explicit links are desired (currently the changelog has a setting for explicit sha links) then additional code for handling issue refs and arbitrary links is needed.

Of course this works as referenced issues are found in the title, or if the body is rendered per commit. Does not work if only the title is rendered and the references are found in the body, which I think is the use case you're after, isn't it?

[gotson]

Of course this works as referenced issues are found in the title, or if the body is rendered per commit. Does not work if only the title is rendered and the references are found in the body, which I think is the use case you're after, isn't it?

Yes indeed. The link references is secondary.

[aalmiray]

Released in v1.4.0 -> https://github.com/jreleaser/jreleaser/releases/tag/v1.4.0