Cherry-picker should copy release notes

[alculquicondor]

What would you like to be added:

Copy release notes into the cherry-pick PR.

Why is this needed:

To simplify the release process.

Completion requirements:

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

The artifacts should be linked in subsequent comments.

[alculquicondor]

/assign @trasc

[trasc]

@alculquicondor in the recent generated PRs , with the exception of #1704 case in which the source PR #1666 where the description has no release-note block, the release notes are copied. Am I missing something?

[alculquicondor]

I copied them manually

[trasc]

I copied them manually

It's strange, the implementation is in-place https://github.com/kubernetes/test-infra/blob/6d0a63230e80cf0138f83a65086f12d441756eb3/prow/external-plugins/cherrypicker/server.go#L46.

[alculquicondor]

uhm... then maybe it was only for the cherry-picks done with the script in /hacks

[trasc]

That one has indeed an hard-coded empty release note.

kueue/hack/cherry_pick_pull.sh

Lines 147 to 149 in 4c1c6d6

	For details on the cherry pick process, see the [cherry pick requests](https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md) page.
	\`\`\`release-note
	\`\`\`

[alculquicondor]

Uhm... this code seems to point out that it indeed looks at parent PRs https://github.com/kubernetes/release/blob/355b4aad5b3593b7aa0764fe5b166660bfbdd686/pkg/notes/notes.go#L1048

[alculquicondor]

I'll pay some attention next time I do a release to understand what I was doing wrong.

/unassign trasc

[alculquicondor]

/assign trasc
Based on comments in kubernetes/test-infra#31929

[trasc]

With kubernetes/release#3468 the defaulting to the original PR's release note if not present in the current one should work for both cherry-pick methods (bit an hack script) regardless of merge method used.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.