-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switching to Kubernetes release-notes tool #8292
Comments
@kubernetes-sigs/cluster-api-release-team |
cc @vincepri |
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) |
/triage accepted |
/assign I will start looking into what it'll take to swap over - otherwise the effort in 9249 does not seem trivial |
The main "cons" I have found are:
and other notes:
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 ...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. |
/priority backlog |
@cahillsf Given the investment in our current tool. Not sure if we still want to consider moving away from it |
@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 |
/close Let's reopen if necessary (or open a new one) |
@sbueringer: Closing this issue. In response to this:
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. |
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
The text was updated successfully, but these errors were encountered: