LetsTimeIt / DungeonTools

Fork of Nnoga's Mythic Dungeon Tools addon to restore mob data and improve upon the base code!
GNU General Public License v2.0
281 stars 74 forks source link

Proper Changelog For Releases #70

Open ueberBrot opened 3 years ago

ueberBrot commented 3 years ago

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.

srenauld commented 3 years ago

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.

ueberBrot commented 3 years ago

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 😞 .

srenauld commented 3 years ago

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: image

ueberBrot commented 3 years ago

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.

srenauld commented 3 years ago

@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 👍 )

ueberBrot commented 3 years ago

@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/release-changelog-builder-action@v1.3.1
  with:
    configuration: ".github/configuration.json"        
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Example:

image