Release Process

Change milestone

Create a new GitHub milestone for the next release
Change milestone applier so new changes can be applied to the appropriate release
- Open a PR in https://github.com/kubernetes/test-infra to change this line
  - Example PR: https://github.com/kubernetes/test-infra/pull/16827

Ensure that CI is stable

Before releasing always ensure CI is stable. Check Prow CAPG dashboard

Ensure you have a GITHUB_TOKEN and are logged into GCP

If you don’t have a GitHub token, create one by going to your GitHub settings in Personal access tokens. Make sure you give the token the repo scope. If you have one, make sure it has the right scope and it is not expired.

Configure gcloud authentication:

gcloud auth login <your-community-email-address>

Create the branch, new version tag, staging image

Please fork https://github.com/kubernetes-sigs/cluster-api-provider-gcp and clone your own repository with e.g. git clone git@github.com:YourGitHubUsername/cluster-api-provider-gcp.git. kpromo uses the fork to build images from.
Add a git remote to the upstream project. git remote add upstream git@github.com:kubernetes-sigs/cluster-api-provider-gcp.git
If this is a major or minor release, create a new release branch and push to GitHub, otherwise switch to it, e.g. git checkout release-1.7.
If this is a major or minor release, update metadata.yaml by adding a new section with the version, and make a commit.
Update the release branch on the repository, e.g. git push origin HEAD:release-1.7. origin refers to the remote git reference to your fork.
Update the release branch on the repository, e.g. git push upstream HEAD:release-1.7. upstream refers to the upstream git reference.
Make sure your repo is clean by git standards.
Set the environment variable VERSION which is the current release that you are making, e.g. export VERSION=v1.7.0, or export VERSION=v1.7.1). Note: the version MUST contain a v in front. Note: you must have a gpg signing configured with git and registered with GitHub.
Create a tag locally git tag -s -a $VERSION -m $VERSION -s flag is for GNU Privacy Guard (GPG) signing.
Make sure you have push permissions to the upstream CAPG repo. Push tag you’ve just created git push <upstream-repo-remote> $VERSION. <upstream-repo-remote> must be the remote pointing to github.com/kubernetes-sigs/cluster-api-provider-gcp.
Pushing this will create the tag and this will automatically trigger a ProwJob to publish images to the staging image repository.

Generate release manifests and release notes

make release from repo, this will create the release artifacts in the out/ folder. It is recommended to verify that the artifact file infrastructure-components.yaml points to the new image.
Install the release-notes tool according to instructions
Generate release-notes (requires exported GITHUB_TOKEN variable, ensure the TOKEN is not expired!):

Run the release-notes tool with the appropriate commits. Commits range from the first commit after the previous non-beta release to the newest commit of the release branch. Set branch to the release branch you are cutting this release from. For example if this is release v1.11.z, branch is going to be release-1.11. When this finishes it will log the path to the temporary file where the notes have been written.
```
release-notes --org kubernetes-sigs --repo cluster-api-provider-gcp \
--start-sha 1cf1ec4a1effd9340fe7370ab45b173a4979dc8f  \
--end-sha e843409f896981185ca31d6b4a4c939f27d975de
--branch <NEW_RELEASE_BRANCH_OR_MAIN_BRANCH>
```
Open the output temporary file logged by the tool and manually format and categorize the release notes

Prepare release in GitHub

Create the GitHub release in the UI

Go to: https://github.com/kubernetes-sigs/cluster-api-provider-gcp/releases
Create a draft release with the output from above in GitHub and associate it with the tag that was created
Copy paste the release notes
Upload artifacts from the out/ folder
Leave everything unchecked and click “Save Draft”

Promote image to prod repo

Images are built by the push images job after pushing a tag.

To promote images from the staging repository to the production registry (registry.k8s.io/cluster-api-provider-gcp):

Wait until images for the tag have been built and pushed to the staging repository by the push images job.
If you don’t have a GitHub token, create one by going to your GitHub settings in Personal access tokens. Make sure you give the token the repo scope.
Create a PR to promote the images to the production registry:
```
# Export the tag of the release to be cut, e.g.:
export VERSION=v1.11.0-beta.0
export GITHUB_TOKEN=<your GH token>
make promote-images
```
Notes:
- make promote-images target tries to figure out your Github user handle in order to find the forked k8s.io repository. If you have not forked the repo, please do it before running the Makefile target.
- if make promote-images fails with an error like FATAL while checking fork of kubernetes/k8s.io you may be able to solve it by manually setting the USER_FORK variable i.e. export USER_FORK=<personal GitHub handle>.
- kpromo uses git@github.com:... as remote to push the branch for the PR. If you don’t have ssh set up you can configure git to use https instead via git config --global url."https://github.com/".insteadOf git@github.com:.
- This will automatically create a PR in k8s.io and assign the CAPV maintainers.
Merge the PR (/lgtm + /hold cancel) and verify the images are available in the production registry: - Wait for the promotion prow job to complete successfully. Then verify that the production images are accessible:
```
docker pull registry.k8s.io/cluster-api-gcp/cluster-api-gcp-controller:${VERSION}
```

Location of image: https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api-gcp/GLOBAL/cluster-api-gcp-controller?rImageListsize=30

Release in GitHub

Go back to the GitHub release in the UI

Edit the draft release previously created in GitHub Releases
Check the “Set as the latest release” checkbox
Check the “Create a Discussion for this release” in Announcements checkbox
ONLY CHECK the “Set as a pre-release” checkbox IF it is a vXX.XX.XX-beta.X release
Now, hit “Publish release”
Announce the release

Versioning

cluster-api-provider-gcp follows the semantic versioning specification.

Example versions:

Pre-release: v0.1.1-alpha.1
Minor release: v0.1.0
Patch release: v0.1.1
Major release: v1.0.0

Expected artifacts

A release yaml file infrastructure-components.yaml containing the resources needed to deploy to Kubernetes
A cluster-templates.yaml for each supported flavor
A metadata.yaml which maps release series to cluster-api contract version
Release notes

Communication

Patch Releases

Announce the release in Kubernetes Slack on the #cluster-api-gcp channel.

Minor/Major Releases

Follow the communications process for pre-releases
An announcement email is sent to sig-cluster-lifecycle@kubernetes.io with the subject [ANNOUNCE] cluster-api-provider-gcp <version> has been released

Kubernetes Cluster API Provider GCP