✨ Add automation to create release branch and tags

[CecileRobertMichon]

What this PR does / why we need it: This adds automated release branch and release tags creation via the release github action to enable the CAPI release team to cut releases without needing the maintainers to cut the releases (maintainers still need to be involved to manually hit the "publish" button and to review the release notes PR).

The process becomes as follows:

• Release team (docs/comms manager) opens a PR to add the auto-generated and manually revised release notes for the upcoming release on the main branch
• Release team (lead/everyone) and maintainers review and merge the PR
• Commit on main branch triggers the Create Release Action which will:
  1. Validate the release version
  2. Create a release branch
  3. Create and push release tags
  4. Generate release artifacts
  5. Create a draft release from the tag with artifacts and the checked in release notes

This was tested extensively in my own fork with a different branch and fake/tags, you can see the latest passing run here

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #7128

[CecileRobertMichon]

/cc @kubernetes-sigs/cluster-api-release-team
/cc @kubernetes-sigs/cluster-api-maintainers

[k8s-ci-robot]

@CecileRobertMichon: GitHub didn't allow me to request PR reviews from the following users: kubernetes-sigs/cluster-api-release-team.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @kubernetes-sigs/cluster-api-release-team
/cc @kubernetes-sigs/cluster-api-maintainers

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/test-infra repository.

[CecileRobertMichon]

this is important: the notes must be generated from and checked into the main branch

In theory this should work for all types of releases (alpha, beta, rc, .0, and patch) and I ran through all the scenarios but let me know if you can think of any issues with this...

We always checkout the release branch and fetch the release notes file from the CHANGELOG folder in the main branch in the GH action.

[sbueringer]

I'm not sure how this target would pick up the RELEASE_TAG env var:

release-notes: $(RELEASE_NOTES_DIR) $(RELEASE_NOTES)
	if [ -n "${PRE_RELEASE}" ]; then \
	echo ":rotating_light: This is a RELEASE CANDIDATE. Use it only for testing purposes. If you find any bugs, file an [issue](https://github.com/kubernetes-sigs/cluster-api/issues/new)." > $(RELEASE_NOTES_DIR)/$(RELEASE_TAG).md; \
	else \
	go run ./hack/tools/release/notes.go --from=$(PREVIOUS_TAG) > $(RELEASE_NOTES_DIR)/$(RELEASE_TAG).md; \
	fi

It always seems to generate notes from PREVIOUS_TAG until current commit?

I'm probably missing something

[CecileRobertMichon]

That's a good question. @nawazkh @furkatgofurov7 does notes.go always need to be run from the commit we're releasing from?

[CecileRobertMichon]

Ok, I checked and you were correct @sbueringer, the notes tool will generate notes from PREVIOUS_TAG to HEAD so this means base notes need to be generated from the release branch still, clarified the instructions.

The PR should still be open in the main branch.

		commitRange = lastTag()
		cmd = exec.Command("git", "rev-list", commitRange+"..HEAD", "--merges", "--pretty=format:%B") //nolint:gosec

[furkatgofurov7]

Awesome job, thanks @CecileRobertMichon. This should help to release team activities a lot 🎉

Few nits/questions:

[g-gaston]

love this, thanks a lot @CecileRobertMichon
lgtm

[CecileRobertMichon]

/assign @vincepri @sbueringer @furkatgofurov7 @g-gaston @nawazkh

[nawazkh]

Looks good to me, thanks for creating this automation!
/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 9fb495e676e077787679450a9fffd5d54babd5f6

[CecileRobertMichon]

Would be good to get reviews from other maintainers

/assign @vincepri
/cc @killianmuldoon @fabriziopandini @enxebre

[sbueringer]

Thank you very much!

Really nice work :)

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: b4a8de39b61f87d43e883205d95aaa1777599311

[vincepri]

Do we need to handle RCs as well?

There might be an edge case I think here where we're curring beta/alphas on a specific release branch, rather than on the main one. Usually this is vey rare, or it might never happened; but might be good to document?

[CecileRobertMichon]

RC is where the release branch gets created for the first time. alpha/beta are created from the main branch. This is documented in https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md.

[sbueringer]

Q: If I see correctly, in case we have some edge case we can always work around this action by just doing everything manually, right? (and then at the end add the changelog to the repo)

[CecileRobertMichon]

Correct @sbueringer

[killianmuldoon]

/lgtm

Looking forward to seeing this working!

[sbueringer]

I would say let's give it a few more days and if there are no objections until then merge on Monday

[sbueringer]

/approve
/hold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbueringer]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[killianmuldoon]

I would say let's give it a few more days and if there are no objections until then merge on Monday

+100

[sbueringer]

@CecileRobertMichon Thank you very much for making this happen :)

/hold cancel

[g-gaston]

/area release