Automate release branch and tag creation

[CecileRobertMichon]

User Story

As part of improving release process and setting up a release v-team (#7110), we need to make releasing accessible to more people, specifically, those who don't have write permissions on the repo (i.e. everyone except approvers), without making the overall process less secure or introducing risk of a bad actor being able to create a release. In order to do so, we should make as much of the process automated as possible.

One aspect of the release that is still manual is creating a release branch (for minor releases) and pushing a release tag (that then triggers the release GitHub Action).

Detailed Description

One idea that comes to mind is to make release branch and tag creation also run as part of the Github Action, and to make the Action get triggered on a PR merge. That way, approvers would need to "approve" the release run, but anyone could open the PR to trigger it. What contents those PRs would contain is TBD. Could be simply the tag in a file, or the release notes (but then that is currently dependent on the existence of the tag so we need to be reworked).

Open other ideas if others have suggestions.

Anything else you would like to add:

Follow-ups:

• We also have to update the release-tasks documentation accordingly

/kind feature

[fabriziopandini]

/triage accepted

[CecileRobertMichon]

I haven’t looked at what k/k does but here is some prior art: https://github.com/Azure/aks-engine/blob/master/.github/workflows/create-release-branch.yaml

The main thing to figure out here is what should trigger the action. Right now the automation is triggered when a tag is pushed, but that requires write permissions on the repo. If we make it a GitHub Action with manual triggers, it would still require elevated permissions to run it and there is no approval process (anyone with those permissions can click run).

My initial thought is that having the automation get triggered from a PR merge that adds release notes would work well. Anyone can open a PR and there is a well defined proccess already for who can approve PRs for what directories. We can even make the release team OWNERS of a specific directory. We have automation to generate release notes but those often need to be manually curated before publishing the release. So this would also allow the release notes to be "reviewed" and edited by the release note manager as part of the PR review process.

[ykakarap]

Sounds good. I will do some research on what k/k does and see if there are any insights/tools we can use from there. That combined with the PR for release notes to trigger the action sounds like a good idea.

I will report my findings here.

[sbueringer]

Agree with all above.

Just small clarification. The following actions require additional permissions today:

• create a GitHub milestone (I would ignore this one for now)
• create a release branch
• create a tag
• create/update/publish a release

Highest priority definitely have the last 2. Creating a GitHub milestone and a release branch only has to be done once per release.

[sbueringer]

@ykakarap Let's please also ask around in sig-testing / sig-k8s-infra / release team channels if there is already tooling to automate the things I mentioned in the comment above.

Obviously they have tooling to manage things like GitHub orgs & teams. So we're not too far off with what we want. There also might be a chance for collaboration with one of those SIGs.

[sbueringer]

Note:

• We also have to update the release-tasks documentation accordingly

(also added above as follow-up)

[k8s-triage-robot]

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:

• 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[fabriziopandini]

/lifecycle frozen

[killianmuldoon]

/assign

Will look into this as part of the v1.5 release cycle

[sbueringer]

Let me know if you want to brainstorm potential solutions

[killianmuldoon]

/unassign

Myself and @joekr took a look at this during the v1.5 release cycle. There's a number of issues with doing this in any sort of "automated" way. The base issue is around the security model of CAPI releases and whether it's a good idea to hand those over to something like Github actions or maintain a Github account that would have those permissions. There is no obvious good tradeoff with any of these options.

The next best avenue of investigation - this idea came from @CecileRobertMichon during the CAPI community meeting on July 12th - is to see if it's feasible to create a Github role - hopefully using k/k automation - that gives sufficient rights to the release lead to be able to do releases. If we can create a role that fulfills this we might be able to base future automation around this specific set of permissions.

The tasks that the release lead currently needs help with are now enumerated here: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#maintainer