Conversation
|
View the release result at https://github.com/Goooler/keep-a-changelog/releases/tag/v1.1.1. |
GitHub releases will be triggered by tags pushing, you can also add some steps like website deployment in this workflow.
| with: | ||
| release_notes_file: RELEASE_NOTES.md | ||
| - name: Create release | ||
| run: gh release create ${{ github.ref_name }} --notes-file RELEASE_NOTES.md |
There was a problem hiding this comment.
We can try --notes-from-tag option here, but there are some workarounds for it. See Goooler#1.
|
Interesting @Goooler, I see this relies on https://github.com/ffurrer2/extract-release-notes I don't really need automated tooling to produce GitHub Release posts on this project since they're infrequent but it's a really interesting option for folks who prefer using their changelog text files as a source of truth and derive proprietary release posts from GitHub from them. It makes me thing Keep a Changelog 2.0 should recommend this pattern: if you're going to use hosting-platform specific release posts, copy/generate them from the canonical changelog file. Thank you. I'm not going to merge this since it adds a dependency I don't really need but I think it's a good idea. 😃 |
|
And the feature request for GH cli was addressed to cli/cli#9276. |
As discussed in a recent [PR][1], people should treat their changelogs as canonical sources given their portability. Release posts can easily be created manually or automatically since the Keep a Changelog format is easy to parse for both humans and machines. [1]: #629 (comment)
|
Good to see! |
3 participants
GitHub releases will be triggered by tags pushing, you can also add some steps like website deployment in this workflow.