Improve OLM Changelog

[awgreene]

Feature Request

Is your feature request related to a problem? Please describe. It is difficult to know which OLM features are available in each released version of OLM. Currently, OLM's CHANGELOG.md is generated from commit headers and does not describe the changes in detail, leaving users to inspect commit messages and the OLM code to understand the changes introduced..

Describe the solution you'd like Update OLM PRs to include a template that is used to generate a changelog. The SDK has already introduced a template that could be leveraged by OLM to generate a better changelog. An example of the Changelog generated by the SDK can be found here.

[timflannagan]

Recently, github has rolled out automation for generating release changelogs and the output format is pretty nice. See https://github.com/operator-framework/operator-registry/releases/tag/v1.20.0 for a concrete example.

We currently template out CHANGELOG(s) at release time using goreleaser's built-in changelog generation tooling, but the default output is a list of the comments messages, so we still run into the same problem with verbosity like before. A decent middleground may be to disable that changelog generation behavior (or update goreleaser to reference a template like SDK's), but I think my preference would be the following release workflow:

• A user creates a tag manually and pushes that to the remote tracking the upstream OLM repository
• The release workflow, which is triggered by new tag events, runs the goreleaser job, and creates a draft release that contains all the release artifacts we care about
• A user presses the "Auto-generate release button" for that draft release

The obvious downside is that we now increase manual intervention in the release process, which isn't always ideal, but now we'd at least have a consistent changelog generation (and generally, I'm a fan of github's auto-generated release notes) without having to house a template, or manually embed change types in commit/PR messages like controller-runtime does. Any thoughts @joelanford or @njhale?

[camilamacedo86]

Hi @timflannagan,

We use emojis for controller runtime and Kubebuiler to generate the release notes with a feature, a bug, etc. See:

• Contribution guide (check the emojis): https://github.com/kubernetes-sigs/kubebuilder/blob/master/CONTRIBUTING.md#pr-process
• To ensure that all PR's have valid emojis: https://github.com/kubernetes-sigs/kubebuilder/blob/master/.github/workflows/verify.yml
• And to generate the release notes: https://github.com/kubernetes-sigs/kubebuilder-release-tools

(it is broken now we and have been running the tools manually until we can fix it): For Kubebuilder, when we push a new tag, all is done automatically, and the release notes are added to the page with the assets after we push a new tag. See: https://github.com/kubernetes-sigs/kubebuilder/releases

IHMO would be cool we try to have a standard or indeed adopt the process required to contribute with https://github.com/kubernetes-sigs since it can help contributors. For SDK, we need the changelogs because we need to provide the steps for end-users to update their projects from N to N+1 and btw it was also requested by a kb user see https://github.com/kubernetes-sigs/kubebuilder/issues/2191, which does not show the case for OLM or C+R at all.