release
release copied to clipboard
kubernetes
[notes] Rework getting the number of the origin PR for cherry-picks
What type of PR is this?
/kind feature
What this PR does / why we need it:
Also attempt to get the number of the origin PR for cherry-picks from the PR's branch name besides the commit message.
This way we get the same behavior, using the origin release note if the current one is empty, for the cherry-picks created by the hack/.. script and those created by prow, regardless of the merge strategy used in the project.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Does this PR introduce a user-facing change?
NONE
Get the number of the origin PR for cherry-picks from the PR's branch name instead of the commit message.
Can it be both?
Get the number of the origin PR for cherry-picks from the PR's branch name instead of the commit message.
Can it be both?
If the merge method is "Merge" and found in the commit message the it will be found in the pr's Head.Label. If only found in the commit message, and not in the PR it can be a match over some unrelated string in the commit message body, hence false positive.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: trasc Once this PR has been reviewed and has the lgtm label, please ask for approval from cici37. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@puerco WDYT of this proposal?
For context, in kubernetes-sigs/kueue we use a similar script as k/k, but additionally we use the prow plugin /cherry-pick.
Another fundamental difference is that we also configured squash during merge.
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle rotten - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The PR seems stuck in review for a while now, but it provides a ground work for https://github.com/kubernetes/release/issues/3746. @trasc would it be possible to tidy, minimize the changes in this PR for the ease of reviewing and merging it?
@xmudrii @puerco @kubernetes/release-engineering Can we do something to get this moving?
Get the number of the origin PR for cherry-picks from the PR's branch name instead of the commit message
Note that not all cherry picks are created with the script and don't have the generated branch names, so we should only do this if the branch fits the pattern.
Get the number of the origin PR for cherry-picks from the PR's branch name instead of the commit message
Note that not all cherry picks are created with the script and don't have the generated branch names, so we should only do this if the branch fits the pattern.
We can fully preserve the old behavior and just add extracting the original pr number from the branch name.