search

kubernetes / sig-release

Repo for SIG release
Apache License 2.0
535 stars 386 forks source link

Milestone maintenance enhancements #2386

Open saschagrunert opened 9 months ago

saschagrunert commented 9 months ago

Main improvements are right now:

- [ ] Clear the latest milestone on `master` PR's if they got applied before code freeze as part of a periodic prow job.
- [x] ~~Applying the latest milestone from a list of privileged people (Release Team Leads) during code freeze via the milestone plugin: https://github.com/kubernetes/test-infra/pull/31380~~

Original conversation: https://kubernetes.slack.com/archives/C2C40FMNF/p1700057962137919

cc @kubernetes/release-managers @pohly @Priyankasaggu11929

xmudrii commented 9 months ago

Clear the latest milestone on master PR's if they got applied before code freeze

I'm not sure if Prow plugin is the best fit for that. Plugins usually react to an event (received via GitHub Webhooks) for a concrete PR. While it's technically doable to remove milestone from multiple PRs, I'm slightly concerned about issues that might arise from that (e.g. concurrency issues).

I think it would be better to have a ProwJob to handle that, but we would need to handle credentials for GitHub in some way.

Check that PRs have lgtm and approved labels before applying the latest milestone during code freeze

This is not going to solve another part of the issue: someone who isn't on the release team can use /milestone to set the milestone and get the PR merged without ACK from the Release Team Leads. I think it might be better to change the plugin that handles the /milestone command to restrict who can apply certain milestones. For example, once the code freeze is in effect, the latest milestone can be set on PRs only by the Release Team Leads and the Release Team Release Signal team. This is something similar to what we did for the cherry-pick-approve plugin recently.

saschagrunert commented 9 months ago

I think it would be better to have a ProwJob to handle that

Something similar to the ci-fast-forward job would work: https://github.com/kubernetes/test-infra/blob/94bd5f880ecc866b2076c116a017f55d80cf6906/config/jobs/kubernetes/sig-k8s-infra/trusted/releng/releng-trusted.yaml#L338-L368

For example, once the code freeze is in effect, the latest milestone can be set on PRs only by the Release Team Leads and the Release Team Release Signal team.

I added the people restriction to the first comment. The main issue was that the milestone got applied before code freeze, which can be addressed with the first point.

saschagrunert commented 9 months ago

Update the issue to reflect the current state. One problem I see right now is that code freeze is nothing we can check from a technical perspective. :thinking:

Edit: Ah we could check for the prow config: https://github.com/kubernetes/test-infra/pull/31164/files

k8s-triage-robot commented 6 months ago

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

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

You can:

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

/lifecycle stale

k8s-triage-robot commented 5 months ago

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:

You can:

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

/lifecycle rotten

xmudrii commented 5 months ago

/remove-lifecycle rotten

k8s-triage-robot commented 2 months ago

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

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

You can:

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

/lifecycle stale

xmudrii commented 1 month ago

/remove-lifecycle stale