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

Provide a method to CC Release Team on cherry-pick PRs to Releases #9212

Closed
cahillsf opened this issue Aug 16, 2023 · 13 comments
Closed

Provide a method to CC Release Team on cherry-pick PRs to Releases #9212

cahillsf opened this issue Aug 16, 2023 · 13 comments
Assignees
Labels
area/release Issues or PRs related to releasing kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@cahillsf
Copy link
Member

cahillsf commented Aug 16, 2023

What would you like to be added (User Story)?

As a release team member I would like to provide a way for cherry-pick PR authors to CC the release team on cherry-pick PRs where applicable to minimize manual burden on PR author or maintainer.

Detailed Description

CAPI Release team should be cc'ed on cherry-pick PRs to releases. Currently we see two paths forward:

  • Best way to do it, is probably by extending the cherrypicker in test-infra
    • the cherrypicker does already allow for assigning issues via the prowAssignments option (link)
  • Alternative or temporary solution could be a GitHub action in the cluster-api repo

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
/area release
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. area/release Issues or PRs related to releasing needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Aug 16, 2023
@cahillsf
Copy link
Member Author

/assign cahillsf

@killianmuldoon
Copy link
Contributor

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Aug 16, 2023
@cahillsf
Copy link
Member Author

posted in #sig-testing to see if the cherrypicker is accepting contributions or if they have other ideas for how we can move forward

@furkatgofurov7
Copy link
Member

/triage accepted

Thanks for looking into it!
This is tracked in tracking umbrella issue: #9104

@sbueringer
Copy link
Member

sbueringer commented Aug 16, 2023

As a release team member I would like a way to ensure the release team is cc'ed on cherry-pick PRs to minimize manual overhead in release maintenance.

How does cc'ing the release team minimize the manual overhead in release maintenance?

@furkatgofurov7
Copy link
Member

How does cc'ing the release team minimize the manual overhead in release maintenance?

Well, maybe it is confusing to state "manual overhead in release maintenance" but rather "manual burden to PR author or maintainer to always cc RT in cherry pick PRs"

@sbueringer
Copy link
Member

sbueringer commented Aug 16, 2023

I think I'm missing a crucial piece. Why do we want to either manually or automatically always cc the release team on all cherry-pick PRs?

@cahillsf
Copy link
Member Author

Correct me if I am wrong, Furkat, but I believe the intention here is not to always CC the release team on all the cherry-pick PRs, but provide a method to make it easier to CC RT on cherry-pick PRs where applicable

@sbueringer
Copy link
Member

sbueringer commented Aug 16, 2023

Btw sorry for the stupid questions, I'm mostly trying to understand what workflow we're aiming for :)

@furkatgofurov7
Copy link
Member

furkatgofurov7 commented Aug 16, 2023

I think I'm missing a crucial piece. Why do we want to either manually or automatically always cc the release team on all cherry-pick PRs?

That came up in as one of the improvement tasks back from 1.4 RT. So basically, in case where we decide to cherry pick a PR and that needs RT's attention (don't ask me if that would be a case ever 😄) or at least they should be aware of it, then this automation would be used. Although, now I am thinking we might be complicating things to avoid one liner comment to tag a RT GH handle if considered needed.

@furkatgofurov7
Copy link
Member

Correct me if I am wrong, Furkat, but I believe the intention here is not to always CC the release team on all the cherry-pick PRs, but provide a method to make it easier to CC RT on cherry-pick PRs where applicable

Yes, that is my understanding @cahillsf

@sbueringer
Copy link
Member

sbueringer commented Aug 16, 2023

I think if we only want to cc the release team on some cherry-pick PRs it's probably easier to do it on those PRs vs trying to find a way to parameterize the cherry-pick.

This can be also generalized to other folks and other PRs, aka if I want someones attention on a PR I just cc them (just joking a bit :)). Seems like we found out that we don't necessarily need to automate this (anymore).

@cahillsf
Copy link
Member Author

sounds good - seems like this is a "Won't Do". Closing out the issue

@cahillsf cahillsf closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2023
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 kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
Status: Cancelled/Won't do
Development

No branches or pull requests

5 participants