Switching to Kubernetes release-notes tool

[oscr]

Background

In #7766 @CecileRobertMichon mentioned capz uses the Kubernetes release notes generating tool. Having looked at it, I would like to discuss the pros / cons of using it instead of the notes tool in capi.

I think it would be an advantage to use the same tool as Kubernetes and capz/capa etc. It would allow knowledge reuse between projects, we would gain functionality without having to implement it ourselves and we would get a consistent release notes look and feel between capi, capz, k/k etc.

References from capz

PR release notes section: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/17332db12a16a856ac250c7f5700aabdb9f368f4/.github/pull_request_template.md?plain=1#L35-L42

Release notes example: https://github.com/kubernetes-sigs/cluster-api-provider-azure/releases/tag/v1.8.0

Makefile target to generate notes: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/17332db12a16a856ac250c7f5700aabdb9f368f4/Makefile#L627-L633

[ykakarap]

@kubernetes-sigs/cluster-api-release-team

[oscr]

cc @vincepri

[sbueringer]

Do we know if there are other pro/cons apart from the ones already mentioned in the issue description?

(P.S. I personally won't get to taking a closer look at this before I'm back from PTO after easter)

[fabriziopandini]

/triage accepted
I don't have strong opinions, but I would add a goal to preserve a nice and lightweight experience for all the contributors to the discussion (the current process is totally transparent for the majority of the PRs, which do not require additional release notes)

[mjlshen]

We discussed this briefly today, one nice thing is that it would likely take care of #9249 by default as well as being configurable via a go-template which would simplify tasks like #9248

[mjlshen]

/assign

I will start looking into what it'll take to swap over - otherwise the effort in 9249 does not seem trivial

[mjlshen]

The main "cons" I have found are:

• there's no support for the area/* labels that we use in cluster-api (we'd need to swap over to kind/* labels)
• release notes need to be explicitly specified on the PR

and other notes:

• It is go template-based, however the available variables are fairly limited: https://github.com/kubernetes/release/blob/7cac31e9ed4b8afe87af6d34a504f8ee23477ab8/pkg/notes/document/document.go#L44-L52 and https://github.com/kubernetes/release/blob/7cac31e9ed4b8afe87af6d34a504f8ee23477ab8/pkg/notes/document/document.go#L204-L207 we can't currently get a PR title to handroll our current release notes format, for example

If we didn't want to change our workflow too much, my first impression is that we could possibly contribute upstream to expose the concept of a Note as an interface so that in cluster-api we could implement our own Note to specify the area labels we care about (currently hardcoded kind labels) and use PR titles as release notes (currently must be explicitly specified elsewhere in the PR).

...or we could borrow much of the logic and refactor our existing notes tool? It does have a lot of nice features, it's just opinionated.

[furkatgofurov7]

The main "cons" I have found are:

• there's no support for the area/* labels that we use in cluster-api (we'd need to swap over to kind/* labels)
• release notes need to be explicitly specified on the PR

and other notes:

• It is go template-based, however the available variables are fairly limited: https://github.com/kubernetes/release/blob/7cac31e9ed4b8afe87af6d34a504f8ee23477ab8/pkg/notes/document/document.go#L44-L52 and https://github.com/kubernetes/release/blob/7cac31e9ed4b8afe87af6d34a504f8ee23477ab8/pkg/notes/document/document.go#L204-L207 we can't currently get a PR title to handroll our current release notes format, for example

If we didn't want to change our workflow too much, my first impression is that we could possibly contribute upstream to expose the concept of a Note as an interface so that in cluster-api we could implement our own Note to specify the area labels we care about (currently hardcoded kind labels) and use PR titles as release notes (currently must be explicitly specified elsewhere in the PR).

...or we could borrow much of the logic and refactor our existing notes tool? It does have a lot of nice features, it's just opinionated.

Thanks for taking a look at it. I am fine with both options and what the community thinks is the right way to go, however using the upstream tool seems to bring the fixes to the other issues we are trying to work around in our release note generation tool with additional nice features (i.e CVEList) on top.

[fabriziopandini]

/priority backlog
/kind feature

[sbueringer]

@cahillsf Given the investment in our current tool. Not sure if we still want to consider moving away from it

[cahillsf]

@sbueringer interesting point. yeah im fine with closing this issue, going through the comments here (and to your point) both of the tasks mentioned here #8292 (comment) have been completed with the current tool

[cahillsf]

cc @adilGhaffarDev

[sbueringer]

/close

Let's reopen if necessary (or open a new one)

[k8s-ci-robot]

@sbueringer: Closing this issue.

In response to this:

/close

Let's reopen if necessary (or open a new one)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.