🐛 Deduplicating area in pr title in release notes

[Dhairya-Arora01]

What this PR does / why we need it:Deduplicating prefix in release notes as stated in #9104 Release Notes section 3rd task

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes: #9190
Part of: #9104

[k8s-ci-robot]

Hi @Dhairya-Arora01. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[killianmuldoon]

/ok-to-test

[furkatgofurov7]

@Dhairya-Arora01 hey, thanks for the PR.

Can you please create a separate issue where this PR tries to tackle it, that is because we agreed to create new issues for each individual sub-tasks since #9104 is an umbrella issue. Once you create a separate issue dedicated for this PR, you can update the PR description with:

Fixes: #<newly created issue>
Part of: #9104 

[Dhairya-Arora01]

@Dhairya-Arora01 hey, thanks for the PR.

Can you please create a separate issue where this PR tries to tackle it, that is because we agreed to create new issues for each individual sub-tasks since #9104 is an umbrella issue. Once you create a separate issue dedicated for this PR, you can update the PR description with:

Fixes: #<newly created issue>
Part of: #9104 

Sure

[g-gaston]

thanks a lot!

[g-gaston]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 579e4e67b7e89f98eba7daefbf3995add1523a8a

[furkatgofurov7]

Thanks @Dhairya-Arora01

/lgtm
/cc @sbueringer @killianmuldoon
@kubernetes-sigs/cluster-api-release-team

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: b9520910a3b756a48fc0a376ebb629a91db29f22

[g-gaston]

this made me look at the implementation and I think it might a bit dangerous
The "search" we do is global, so if a PR title has the prefix in the middle of the string, we will "cut" from there. Instead, I think it would be better if we remove the area only when we find it at the start of the string.

example of problematic title:
Update API:Machine with new field
will be converted to
Machine with new field

[Dhairya-Arora01]

@g-gaston the area that we are removing is user friendly area

cluster-api/hack/tools/release/notes.go

Line 459 in 46412f0

area, err = getAreaLabel(c.merge)

Example in our case test/e2e: but the user friendly area is e2e and it makes sense to remove whole test/e2e:

Also we are searching for area + ":" to remove , and i think it doesn't makes sense to have area: in between the PR title.
WDYT?

[g-gaston]

Also we are searching for area + ":" to remove , and i think it doesn't makes sense to have area: in between the PR title.

I don't disagree but I don't want to make that restriction for PR titles. The idea here is to cleanup PR titles for the release notes when we can, not to impose more rules over PR titles. I would prefer to restrict the cleanup to just the beginning of the title. If that means we can't automatically cleanup some titles and we do it manually, it's an ok tradeoff.

Example in our case test/e2e: but the user friendly area is e2e and it makes sense to remove whole test/e2e:

I understand what your are saying about that PR specifically, but we can't really catch all the possible variations. What if the author starts the PR title with Test/E2E? We won't be able to catch that with the current logic, although it's still duplicated.

If what you want is to be able to catch composed prefixes with the area, why don't you use a regex? That way you can restrict it to start at the beginning of the title and maybe even make it case insensitive.
Something like (I haven't tested this btw, just a direction to explore)

`(?mi)^\S*/e2e:\s*`

[sbueringer]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbueringer]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[furkatgofurov7]

This looks good to me, but leaving it to others take another look after suggestions

/cc @g-gaston

/lgtm
/hold

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: b068bf696c6ad261923479cc0a486537fbd59f01

[g-gaston]

/lgtm
/unhold

Thanks!