Changelog generator discussion

[gniftygnome]

From #25:

What about adding a changelog generator from commits 🤔

From #28:

We do limit the changelog to ten lines, though. I think I recall mention in one of the MPP issues of having MPP generate changelogs from GH. Ferry does this, if you're interested. However, Ferry requires the version numbers for the previous published version and the new published version as properties. Even so, it's a messy process.
https://github.com/TerraformersMC/GradleScripts/blob/2.6/ferry.gradle#L35-L96
[...]
As for the changelogs I think this is worth a new issue to discuss. For Fabric and my own projects ive been using: https://github.com/FabricMC/fabric-action-scripts/blob/main/src/changelog.ts the problem is this is specific to github actions.

So, here's a new issue!

Personally, I'm fine with the current situation, since Ferry already has changelog generation we like. If changelog generation gets added to MPP, ideally it would be optional. A couple of differences I think I see:

• Ferry only picks changelog lines starting with - which allows using * to generate programmer-facing log lines that don't go into the user-facing publications.
• Instead of the last action run, Ferry requires the user tell it the last tag, which means to run the workflow we have to go look that up first. However, it makes the behavior a bit more flexible and is not dependent on GH actions.
• There are some configurables for Ferry's changelog generation:

# Changelog Options
# changelog_hide_unimportant_commits tries to hide Merge commits
changelog_hide_unimportant_commits=true
changelog_max_commit_search=200
discord_webhook_changelog_line_limit=10

[modmuss50]

ideally it would be optional

100%, it would be opt-in and you could always use your own soltuion, in the same way you can now.

Ferry requires the user tell it the last tag, which means to run the workflow we have to go look that up first. However, it makes the behavior a bit more flexible and is not dependent on GH actions.

I wonder if the solution would be to have multiple ways to supply the last commit, either manually, from the last succesfull GHA run (same as the fabric scripts), or the last tag on the branch?

The API could be something along the following lines?

publishMods {
    changelog = githubActions {
        workflow = "release.yml"
    }
    
    changelog = git {
        from = "v1.0.0" // Tag name
    }
}

[gniftygnome]

The API could be something along the following lines?

I like this.