-
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
🌱 cc @cluster-api-release-team
when auto-opening the PR to promote images from staging to prod
#7487
🌱 cc @cluster-api-release-team
when auto-opening the PR to promote images from staging to prod
#7487
Conversation
Add @cluster-api-release-team to the list of people/teams CC'd on the PR to promote images from staging to production registry.
Keywords which can automatically close issues and at(@) or hashtag(#) mentions are not allowed in commit messages. The list of commits with invalid commit messages:
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. I understand the commands that are listed here. |
Keywords which can automatically close issues and at(@) mentions are not allowed in the title of a Pull Request. You can edit the title by writing /retitle in a comment.
When GitHub merges a Pull Request, the title is included in the merge commit. To avoid invalid keywords in the merge commit, please edit the title of the PR.
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. I understand the commands that are listed here. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@@ -27,4 +27,4 @@ cd "${REPO_ROOT}" && make ${YQ_BIN} >/dev/null | |||
|
|||
KEYS=() | |||
while IFS='' read -r line; do KEYS+=("$line"); done < <(${YQ_PATH} e '.aliases["cluster-api-maintainers"][]' OWNERS_ALIASES) | |||
echo "${KEYS[@]/#/@}" | |||
echo "${KEYS[@]/#/@} @cluster-api-release-team" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this won't work cross-org (kubernetes => kubernetes-sigs) as the GItHub team is created in kubernetes-sigs
Tested it here: kubernetes/k8s.io#4418 (comment)
Doesn't looks like it works. Not sure if there is any way to do it (didn't spent to much time on research)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't find a way to easily do this, I think it's fine to mention folks manually or eventually put the release team info in a format where we can also grep for GitHub IDs (might get a bit hacky)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm thinking about it some more. Could be beneficial to have the release team info in some structured format (YAML with arrays?) anyway to:
- easily open the PR for the Slack group
- easily open the PR for the GitHub team
I wouldn't go so far as to automatically generate those 2 PRs, but for the promotion PR it should be realistic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might want an OWNERs file for release notes as per #7128 so in that case having the release team defined in OWNERS_ALIASES would be useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we cc the same set of people for the image promotion PR vs. OWNERS for release notes?
(or would it be the entire release team for both?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not necessarily, we could be more granular if we wanted to and have a different OWNERs group for each release team role
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds fine to me in general, but I guess we have to figure out the details of who exactly gets which reviewer or approver (?) rights.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest having a group for the release team leads and one for the release team shadows; both gets the email, the first approve
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
@ykakarap @sbueringer what about closing this PR and moving this idea in the tracking issue for release improvements |
@ykakarap given how we currently work and that it's non trivial to do. Do we still need this PR? |
Lets close this PR for now. The item is already tracked in the the release improvements if we ever want to get back to this. /close |
@ykakarap: Closed this PR. 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. |
What this PR does / why we need it:
This PR adds the @cluster-api-release-team to the list of people/teams CC'd on the PR to promote images from staging to production registry.
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 #
/cc @CecileRobertMichon
/hold until kubernetes/org#3802 is merged