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)