Changelog automation

[ArthurSens]

On every new release, we need to provide a list of changes that made it into the release. This log of changes is maintained in the CHANGELOG.md file.

Updating the Changelog file requires manual effort from maintainers, it demands searching through commit history, analyzing which PRs had user-facing changes, and which PRs hadn't, writing clear messages describing the change, etc.

This whole process could receive some improvements through automation.

---

This issue concerns researching, proposing, and implementing the Changelog automation for client_golang. The final goal is not to require manual effort from maintainers to go through a big list of commits and hand-picking changelog entries.

---

Related:

https://github.com/googleapis/release-please

xref: cncf/mentoring#1120

[pawarpranav83]

Hi @ArthurSens. I would love to solve this issue for the upcoming LFX program.

[kartikaysaxena]

Hey @ArthurSens, I am quite interested in working upon this issue in the LFX program.

[pawarpranav83]

Hey @ArthurSens, we could use GitHub's Automatic release notes generation feature itself, though we would have to assign labels to PRs and define a yaml file accordingly.

Or do you have any other approach in mind?

[ArthurSens]

Hey folks, thanks for the interest :)

Applications will be done through LFX mentoring website, so we'll have to wait for the official timeline to start working deeply on the proposal. This task alone is also quite small for the LFX program (around 3 months of work), so we're still working on other kinds of automation to add to the project idea (mostly around go version upgrades).

With that said, I believe there's no problem on brainstorming high level ideas like you're doing :)

---

we could use GitHub's Automatic release notes generation feature itself, though we would have to assign labels to PRs and define a yaml file accordingly.

The Github's automatic release notes that I know dump the whole commit history between two releases, and that includes non-user-facing changes. Did they change anything recently that takes PR labels into consideration (and possibly a yaml file?)?

[kartikaysaxena]

Hey @ArthurSens maybe we can use some shell scripting to get hold of the file changes in the PR (using git diff maybe) and set up a yaml file which can contain list of important files which can have some possible user-facing-changes, and if they match it would reflect in the changelog (This may also consider PR labels into consideration such as maybe pull-request-size)

[pawarpranav83]

The Github's automatic release notes that I know dump the whole commit history between two releases, and that includes non-user-facing changes. Did they change anything recently that takes PR labels into consideration (and possibly a yaml file?)?

Yes, we can create a release.yml file, in which we can specify the PRs with specific labels to exclude from release notes or we can also specify labels to include them under certain categories.

In the file, using the configuration options below, specify in YAML the pull request labels and authors you want to exclude from this release. You can also create new categories and list the pull request labels to be included in each of them.

https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

[dvjsharma]

Hello @ArthurSens,
Maintaining CHANGELOG.md is indeed a tedious task especially when no automation is applied. I've done some research on how to implement it in Prometheus, following is a brief:

• First off, we currently don't enforce a standard on commit messages as well as PR's making it difficult for any tool to parse them and automate the release process. A uniform standard must be enforced, example could be <type>(<scope>): <subject>.

  • We can also enforce one commit per PR, and can squash all commits into one. This will eliminate the need to tag PR's and will make it easy for tools to identify commits which needs to be added in CHANGELOG.md as user-facing changes.

• There are many ways available to implement this, but i'm more inclined towards using tools like Goreleaser because of the extensive features they provide, and are highly customizable.

  • Another popular tool among node projects is semantic-release and fortunately a stable version of the tool is available for go projects as well. The details needs to be well researched.
  • If we use GitHub Actions, when the workflow runs becomes a concern. workflow_dispatch trigger may be added to publish a release when we find necessary (when we have enough commits to call it a patch release).

I would appreciate any advice and further improvements on this and since this lies in my domain of knowledge, I would love to take this up in LFX'24 spring term.

[kartikaysaxena]

Hey @ArthurSens @kakkoyun , I have submitted my application for this project including possible implementation for the same. Will be grateful if you take a look at it as I would love to work with Prometheus in this mentorship as it strongly aligns with my interest.

[ArthurSens]

Hi everybody, I can confirm that we've received the applications :)

I understand this is of great interest to all applicants, but please keep the timeline in mind. The application results will be announced on February 27th