New prow plugin: cherry-pick-approved

[Sascha Grunert]

Hey kubefolks,

SIG Release was working on a new prow plugin in the past weeks to simplify the Kubernetes cherry-pick experience for Release Managers [0]. With that we'd like to announce the new cherry-pick-approved prow plugin! It does:

- Accept a list of cherry-pick approvers configured for a particular repository [1]

- If one of those people approve a PR's (by using the GitHub review feature) against a release-1.x branch, then prow validates:

  - That there are no failed tests

  - That labels are correctly set (lgtm + approved, without any hold etc) [2]

- If the above conditions are met, then prow will apply the cherry-pick-approved and remove the do-not-merge/cherry-pick-not-approved label

The workflow is simple and can be re-used by other repositories without having a need to increase the set of permissions of people who volunteer to maintain release branches. We will test the plugin in the upcoming weeks to see how we can improve the workflow even further. 

Possible extensions to the plugin could be:

- Documentation about how to use the plugin and what it does

- Automatically validate cherry-picks across different release branches (we usually apply them in batches)

- Automatically notify release managers if the conditions for cherry-picks match

I created a follow-up issue [3] to track the future efforts.

Are you interested in contributing to the new plugin or any other topic in SIG Release? Awesome, feel free to reach out to us directly via #sig-release or #release-management on Slack or any GitHub issue!

All the best,
Sascha

- on behalf of SIG Release

[0]: https://github.com/kubernetes/sig-release/issues/2083

[1]: https://github.com/kubernetes/test-infra/blob/94022bec/config/prow/plugins.yaml#L1102-L1113

[2]: https://github.com/kubernetes/test-infra/blob/94022bec/prow/plugins/cherrypickapproved/cherrypickapproved.go#L193-L209

[3]: https://github.com/kubernetes/sig-release/issues/2385

[Lubomir I. Ivanov]

On Mon, 4 Dec 2023 at 12:04, Sascha Grunert <sascha...@gmail.com> wrote:
>
> Hey kubefolks,
>
> SIG Release was working on a new prow plugin in the past weeks to simplify the Kubernetes cherry-pick experience for Release Managers [0]. With that we'd like to announce the new cherry-pick-approved prow plugin!
> It does:
>
> - Accept a list of cherry-pick approvers configured for a particular repository [1]
> - If one of those people approve a PR's (by using the GitHub review feature) against a release-1.x branch, then prow validates:
> - That there are no failed tests
> - That labels are correctly set (lgtm + approved, without any hold etc) [2]
> - If the above conditions are met, then prow will apply the cherry-pick-approved and remove the do-not-merge/cherry-pick-not-approved label
>

+1!

please note the last WG LTS meeting had some interesting points about
the cherry pick process:
https://docs.google.com/document/d/1RI_EL35MwQxrHqlWvtQNINhOSWergL3hmOSgC5PeZss/edit#bookmark=id.9yy6mgja0wm6

>> - limit backports to regression / security / data-loss fixes by default
>> - anything beyond that needs justification / careful risk analysis (size, entanglement with other changes, test coverage)
>> - the level of scrutiny changes to master get between code freeze and .0 release is the level we should be applying to backports

> The workflow is simple and can be re-used by other repositories without having a need to increase the set of permissions of people who volunteer to maintain release branches. We will test the plugin in the upcoming weeks to see how we can improve the workflow even further.

curious, do we have recent cases when cherry pick approvers have
blocked a certain cherry pick due to not meeting the defined criteria?
https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md?plain=1

asked differently, the cherry pick process is currently gated by the
cherry pick approvers, but is the criteria applied in practice?

>
> Possible extensions to the plugin could be:
> - Documentation about how to use the plugin and what it does
> - Automatically validate cherry-picks across different release branches (we usually apply them in batches)
>

> I created a follow-up issue [3] to track the future efforts.

also based on recent LTS discussions, we might actually want to not do
that automatically.
backports that regress old MINORs can prove difficult to fix and are
generally much undesired by maintainers and users.

lubomir
--

[Jordan Liggitt]

Simultaneous merge and release of a backport to all active release branches has definitely contributed to increased numbers of regressions in the past. A backport that might have only regressed one minor patch version instead regressed 3+ minor versions simultaneously.

Jeremy opened https://github.com/kubernetes/community/issues/7634 to track improving the requirements we apply to backports.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-re...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-release/CAGDbWi97-sWvq2-8xjeJjVw%3DtqiWp4j2nu95mMj7WkqBOkSLAg%40mail.gmail.com.

[Sascha Grunert]

Thank you for the feedback, folks! I updated the issue and linked them together for more context.

I think this discussion goes into the same direction as: https://github.com/kubernetes/community/issues/7634