DungeonTools
DungeonTools copied to clipboard
LetsTimeIt
Proper Changelog For Releases
If it is not to much trouble I would like to see a proper changelog for the new releases. Maybe adapt a git commit style (maybe Conventional Commits) and from there move to a auto generated changelog and release notes with github actions?
Maybe its just me but I love the commit style and CHANGELOGS look so much better with it.
It's on my list of things to do - I was putting changelogs manually on curseforge, I'll look into a way of doing this and bring back all the manual changelogs to the GH releases.
If I find the time, I will also try to invest it and help you out. But I can't promise it at the moment 😞 .
Okay, I've added the changelogs to both releases; I'll keep this issue open for the automation tracking, but will mark it as an enhancement for now.
Have a quality meme:
I had a quick look into this. And I think the following should be decided first to pick a good integration into the github workflow:
Do you want to adapt a commit style like Conventional Commits or do you want to use Commits without any convention? Depending on that, there are different github actions you could use.
@ueberBrot We're going to go with conventional commits on merge commits, I think. This way, there's a way to easily distinguish what will go in the changelog, it should be exhaustive (since there is no reason to push straight to main or develop when it shows up), and it still leaves the freedom for people on their own commit messages, thus striking a good balance.
(And that way, we can build a changelog by just scanning for commits with more than one parent 👍 )
@srenauld I had a look into a few gh-actions to create release notes. The one I like the most is Release Changelog Builder from mikepenz.
Something that works like you described I did not find.
I will leave you a short tldr here. But it is best to have a look at it yourself.
To get the merged PRs sorted into the right category (Feature, Bug fix, Chore, ...) you create labels that you assign to the PR.
The PRs labeled with ignore take precedence over category labels, allowing to specifically exclude certain PRs.
In a folder in the repository, e.g. in the .github folder or wherever, you create a config file configuration.json or whatever you want to name it. In it, you can define the titles for the release notes and the labels that should be added under it.
something like that:
{
"categories": [
{
"title": "## Features",
"labels": [
"feature"
]
},
{
"title": "## Fixes",
"labels": [
"fix"
]
},
{
"title": "## Other",
"labels": [
"perf",
"refactor"
]
},
{
"title": "## Chores",
"labels": [
"chore"
]
},
{
"title": "## Documentation",
"labels": [
"docs"
]
}
]
}
The release notes are generated and added to the release by integrating the following step into the workflow and adding ${{steps.github_release.outputs.changelog}} to the body gh-action input for the Create Release step.
- name: Build Changelog
id: github_release
uses: mikepenz/[email protected]
with:
configuration: ".github/configuration.json"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Example:
