Update Changelog.md automatically

[vmaerten]

Hello!

First of all, thanks so much for this great tool!

Many projects maintain a changelog.md file. Using GoReleaser’s changelog feature to generate release notes (GitHub in our case) still requires manual updates to changelog.md.

(Example: https://github.com/hashicorp/terraform/blob/main/CHANGELOG.md / https://github.com/grafana/grafana/blob/main/CHANGELOG.md / https://github.com/go-task/task/blob/main/CHANGELOG.md)

One idea could be:

• Add a setting to automatically append the generated changelog to a file (defaulting to changelog.md, but configurable).
• Alternatively, this could be done in an after hook, though that would require .Changelog to be accessible in the templating system.

I understand the user would still need to commit the changes, but this could be automated within the CI.

[caarlos0]

Hey!

Yeah this is something I have in my radar for a while now... I'll prioritize it though.

Just to confirm, you mean append or prepend?
Prepend likely will need a couple of extra rules (e.g. not exactly prepend, as you'll probably add it after the document title and before the previous version), but it's all doable I think 🤔

[vmaerten]

I had prepend in mind, so the newest version comes first in the file.

Should I open an issue on GitHub, or are you tracking it on your end?
Thanks a lot for the tool. It’s amazing to be able to release Task so easily!

[caarlos0]

I'll create an issue from this discussion!

Thanks 🙏🏻

[caarlos0]

Another question: when should it happen? What's the flow you have in mind?

E.g.: run goreleaser changelog before releasing, then tag and run goreleaser release, so the tag has the correct updated changelog? Or run it during goreleaser release and commit the updated file?

[shaftoe]

Jumping into the discussion cause I've started to use Goreleaser (it's awesome!) for a new project I'm working on (https://github.com/runvoy/runvoy) and I thought it would be neat to use the same tool to also update CHANGELOG.md given that's already kind of doing all the work already when creating the GH release page changelog document, so to avoid reinventing again that same wheel.

The release flow at the moment is described here: https://runvoy.github.io/CONTRIBUTING/#release-process
It's not written in stone it's just what works out all right for now, so based on that I'd say point 2 might go from "Update the changelog with the new version and changelog entries" to "Run goreleaser changelog" and have it prepend commits info from the previous release.

[vmaerten]

Hello!
Sorry for the delayed reply. I’ve been quite busy lately.
That’s a great question! Initially, I was considering generating it during the GoReleaser release and then committing the file. But the more I think about it, the more using the GoReleaser changelog directly seems like a solid option.

Naive question: could this be parameterized? For instance, always accessible through goreleaser changelog, but also able to run automatically during a release with a flag or a boolean in the YAML config.

One last note: after discussing with Pete and Andrey (other maintainers), we decided to keep a manual changelog despite the extra effort. That said, I still see value in this feature (e.g. for GoReleaser), but it’s no longer a priority for us.

I mainly rely on CHANGELOG.md to track changes between releases.

[caarlos0]

I'm thinking something like:

goreleaser changelog --template changelog.md.tpl --output changelog.md

and then the template something like

# Changelog 

{{ if .Next }}
## Next

{{ .Changelog }}
{{ end }}

{{ range .Releases }}
## {{ .Tag }} - {{ .Date }}

{{ .Changelog }}

{{ end }}

Then basically it would re-gen the entire changelog when you run it. Not sure yet how good of an idea that is, but might be worth it.

Another idea is to have some sort of marker, e.g. <!-- goreleaser:something --> or something like that, but I think I like the template idea better.

[shaftoe]

Template sounds good to me!

[caarlos0]

The more I think about this, the more I think that it doesn't make too much sense, mostly because I think that the changelog file would not have every commit the release notes have. I think they are 2 different things.

I have a more-or-less working prototype and I didn't like the result.

Will sit on this a bit more - maybe this should be a different tool?

[shaftoe]

mostly because I think that the changelog file would not have every commit the release notes have. I think they are 2 different things.

I'm not sure I understand, I suppose one is simply a subset of the other and matching rules decrete what goes in the subset?

I confess I'm surprised because I initially thought the implementation was already there for the release notes and "unplugging" it from the main flow was kind of trivial, I understand now that's not the case.