Skip to content
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

Improve release note generation tool to handle tag prefixes in PR titles #6160

Closed
2 tasks done
sbueringer opened this issue Feb 17, 2022 · 16 comments · Fixed by #6574
Closed
2 tasks done

Improve release note generation tool to handle tag prefixes in PR titles #6160

sbueringer opened this issue Feb 17, 2022 · 16 comments · Fixed by #6574
Assignees
Labels
area/release Issues or PRs related to releasing good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@sbueringer
Copy link
Member

sbueringer commented Feb 17, 2022

Goal of this issue is to extend our release note generation tool to automatically trim "tag" prefixes of PR titles.

Some context:
We are currently using hack/tools/release to generate our release notes.
This tool lists all merged PRs and then builds a list of release notes by category (essentially a raw version of e.g.: https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.1.0).

For a while now we are creating cherry-pick PRs with the cherry-pick bot which usually are named something like [release-1.1] ✨ Upgrade to Kubernetes 1.23.3 in Quickstart and CI. Up until now we then manually retitled those PRs to drop the prefix so:

  1. the verify action accepts the PR title
  2. the release note generation does not include the tag

We recently merged a change to the verify action to allow tag prefixes (kubernetes-sigs/kubebuilder-release-tools#43). In this issue we can now adjust our generation tool and adopt the new version of the action (we have to wait a bit until there's a new release for it)

So concrete tasks:

/area release
/kind feature
/good-first-issue
Please let me know if there are further questions.

@k8s-ci-robot
Copy link
Contributor

@sbueringer:
This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

  • Why are we solving this issue?
  • To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
  • Does this issue have zero to low barrier of entry?
  • How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

Goal of this issue is to extend our release not generation tool to automatically trim "tag" prefixes of PR titles.

Some context:
We are currently using hack/tools/release to generate our release notes.
This tool lists all merged PRs and then builds a list of release notes by category (essentially a raw version of e.g.: https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.1.0).

For a while now we are creating cherry-pick PRs with the cherry-pick bot which usually are named something like [release-1.1] ✨ Upgrade to Kubernetes 1.23.3 in Quickstart and CI. Up until now we then manually retitled those PRs to drop the prefix so:

  1. the verify action accepts the PR title
  2. the release note generation does not include the tag

We recently merged a change to the verify action to allow tag prefixes (kubernetes-sigs/kubebuilder-release-tools#43). In this issue we can now adjust our generation tool and adopt the new version of the action (we have to wait a day or two until there's a new release for it)

So concrete tasks:

/area release
/kind feature
/good-first-issue
Please let me know if there are further questions.

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.

@k8s-ci-robot k8s-ci-robot added area/release Issues or PRs related to releasing kind/feature Categorizes issue or PR as related to a new feature. good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Feb 17, 2022
@ShivamTyagi12345
Copy link
Member

/assign

@fabriziopandini
Copy link
Member

I don't know if it makes sense to consider in this issue or not but usually in our release notes we group PR by area by adding a prefix, see e.g. https://github.com/kubernetes-sigs/cluster-api/releases
Q. should we add the capability to sort PRs by area, if any (the initial part of the PR title before :)

@sbueringer
Copy link
Member Author

That would be nice. The current version of our release note tool is based on:

cmd := exec.Command("git", "rev-list", lastTag+"..HEAD", "--merges", "--pretty=format:%B") //nolint:gosec

So right now we don't have the data to make it work.
@fabriziopandini WDYT about opening an additional/separate issue to consider this improvement? I think it would be nice but requires a bit of re-thinking how the tool currently works.

@fabriziopandini
Copy link
Member

fabriziopandini commented Feb 18, 2022

I was thinking of something much simpler for the first iteration.
If the PR title has a prefix (implying the prefix has been added manually) use it to sort, all the PR without prefix are sorted as of today
In other words, just a smart sort on top of the output of the command above

@sbueringer
Copy link
Member Author

I was thinking of something much simpler for the first iteration. If the PR title has a prefix (implying the prefix has been added manually) use it to sort, all the PR without prefix are sorted as of today In other words, just a smart sort on top of the output of the command above

Ah got it. Sure.
Should we do it in a second PR once we have the trim prefix in?
Would be just nice to have that first as it immediately helps us by avoiding the retitle's

@ykakarap
Copy link
Contributor

Should we do it in a second PR once we have the trim prefix in?

+1 to separate PRs.

@sbueringer
Copy link
Member Author

/milestone v1.2

@k8s-ci-robot k8s-ci-robot added this to the v1.2 milestone Feb 18, 2022
@sbueringer
Copy link
Member Author

@ShivamTyagi12345 Please let me know if there's something I/we can help you with.

@ShivamTyagi12345
Copy link
Member

I lost track of this issue. Thanks for the Ping,Will Make the PR within a couple of hours

@sbueringer
Copy link
Member Author

I lost track of this issue. Thanks for the Ping,Will Make the PR within a couple of hours

Thank you! No rush

@CecileRobertMichon
Copy link
Contributor

@ShivamTyagi12345 are you still working on this one?

@sbueringer
Copy link
Member Author

@ShivamTyagi12345 Are you currently working on this issue? Please let us know if there's anything we can do to help.

@sbueringer
Copy link
Member Author

/unassign @ShivamTyagi12345
/assign

@sbueringer
Copy link
Member Author

So now we shouldn't have to drop the [release-1.x] prefix of PRs anymore

@sbueringer
Copy link
Member Author

sbueringer commented Jun 7, 2022

Verified, it works, e.g.

## :seedling: Others
- hack/release-notes: trim [release-*] in PR titles (#6606)
- bump kubebuilder-release-tools GitHub action to v0.2.0 (#6575)

For: #6606

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/release Issues or PRs related to releasing good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants