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. If you have multiple gcloud configurations, make sure to activate the one relevant to CAPG first:

# Only needed if you have multiple gcloud configurations
gcloud config configurations list
gcloud config configurations activate <your-capg-config>

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 git checkout -b release-1.7. Otherwise if it is a patch release the branch should already exist to it, fetch the latest and sync up your local branch: e.g. git fetch upstream release-1.7 && git checkout release-1.7 && git reset upstream/release-1.7 --hard.
If this is a major or minor release, update metadata.yaml by adding a new section with the version, and make a commit.
Push new/existing release branch to your repository’s fork, e.g. git push origin HEAD:release-1.7. origin refers to the remote git reference to your fork.
Push new/existing release branch to the upstream 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!):

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.

First, compute the required variables. Review the output and verify the values are correct before proceeding:
```
source ./hack/compute-release-notes-vars.sh
```
Once the values look correct, run the release-notes tool. 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-rev "${PREVIOUS_TAG}" \
--end-rev "${VERSION}" \
--branch "${RELEASE_BRANCH}" \
--required-author "" \
--go-template "go-template:hack/release-notes.tpl"
```
Note: The --required-author "" flag is needed because the tool defaults to only processing commits authored by k8s-ci-robot, which would skip most PRs since CAPG uses squash merges that preserve the original author.
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-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 USER_FORK=<personal GitHub handle> # if needed (see notes below)
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 CAPG 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