From 42d19810a8791fa92539f404c621b547cd496785 Mon Sep 17 00:00:00 2001 From: "tuti." Date: Wed, 20 Nov 2024 11:08:23 -0800 Subject: [PATCH] [release tool] update releasing calico (#9487) (#9509) * update releasing calico - release as draft release - update ghr version to latest (v0.17.0) * update releasing docs --- Makefile | 2 +- metadata.mk | 1 + release/RELEASING.md | 155 +++++++++++++------------- release/pkg/manager/calico/manager.go | 1 + 4 files changed, 81 insertions(+), 78 deletions(-) diff --git a/Makefile b/Makefile index 5cafb8dbc3a..40db26fe5e2 100644 --- a/Makefile +++ b/Makefile @@ -112,7 +112,7 @@ release/bin/release: $(shell find ./release -type f -name '*.go') # Install ghr for publishing to github. bin/ghr: - $(DOCKER_RUN) -e GOBIN=/go/src/$(PACKAGE_NAME)/bin/ $(CALICO_BUILD) go install github.com/tcnksm/ghr@v0.14.0 + $(DOCKER_RUN) -e GOBIN=/go/src/$(PACKAGE_NAME)/bin/ $(CALICO_BUILD) go install github.com/tcnksm/ghr@$(GHR_VERSION) # Build a release. release: release/bin/release diff --git a/metadata.mk b/metadata.mk index e43c57750de..289cdf24eff 100644 --- a/metadata.mk +++ b/metadata.mk @@ -18,6 +18,7 @@ KINDEST_NODE_VERSION=v1.29.10 KIND_VERSION=v0.24.0 PROTOC_VER=v0.1 UBI_VERSION=8.10 +GHR_VERSION=v0.17.0 # Configuration for Semaphore integration. ORGANIZATION = projectcalico diff --git a/release/RELEASING.md b/release/RELEASING.md index f4a1d9db078..07c720bab2b 100644 --- a/release/RELEASING.md +++ b/release/RELEASING.md @@ -1,4 +1,4 @@ -# How to release Calico +# Releasing Calico > **NOTE:** These instructions apply only to Calico versions v3.21 or greater. > For older releases, refer to the instructions in the corresponding `release-vX.Y` branch. @@ -9,8 +9,7 @@ 1. [Verify the code is ready for release](#2-verify-the-code-is-ready-for-release) 1. [Create a release branch](#3-create-a-release-branch) 1. [Performing a release](#4-performing-a-release) -1. [Promoting to be the latest release in the docs](#5-promoting-to-be-the-latest-release-in-the-docs) -1. [Post-release](#6-post-release) +1. [Post-release](#5-post-release) ## 1. Prerequisites @@ -23,19 +22,19 @@ To publish Calico, you need **the following permissions**: - Push access to the Calico DockerHub repositories. Assuming you've been granted access by an admin: - ``` + ```sh docker login ``` - Push access to the Calico quay.io repositories. Assuming you've been granted access by an admin: - ``` + ```sh docker login quay.io ``` - Push access to the gcr.io/projectcalico-org repositories. **Note:** Some of the repos do not yet support credential helpers, you must use one of the token-based logins. For example, assuming you've been granted access, this will configure a short-lived auth token: - ``` + ```sh gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://gcr.io ``` @@ -44,23 +43,21 @@ To publish Calico, you need **the following permissions**: - You must be able to access binaries.projectcalico.org. - To publish the helm release to the repo, you’ll need an AWS helm profile: - Add this to your ~/.aws/config - ``` - [profile helm] - role_arn = arn:aws:iam:::role/CalicoDevHelmAdmin - mfa_serial = arn:aws:iam:::mfa/myusername - source_profile = default - region = us-east-2 - ``` - Your user will need permission for assuming the helm admin role in the production account. + Add this to your `~/.aws/config` -You'll also need **several GB of disk space**. + ```sh + [profile helm] + role_arn = arn:aws:iam:::role/CalicoDevHelmAdmin + mfa_serial = arn:aws:iam:::mfa/myusername + source_profile = default + region = us-east-2 + ``` -Some of the release scripts also require **tools to be installed** in your dev environment: + Your user will need permission for assuming the helm admin role in the production account. -- [Install and configure](https://github.com/github/hub#installation) the GitHub `hub` tool. +You'll also need **several GB of disk space**. -Finally, the release process **assumes that your repos are checked out with name `origin`** for the git remote +Finally, the release process **assumes that your repos are checked out with name `origin`** as the git remote for the main Calico repo. ## 2. Verify the code is ready for release @@ -85,17 +82,17 @@ When starting development on a new minor release, the first step is to create a 1. Create a new branch off of the latest master and publish it, along with a dev tag for the next release. - ``` + ```sh git checkout master && git pull origin master ``` - ``` + ```sh make create-release-branch ``` 1. Checkout the newly created branch. - ``` + ```sh git checkout release-vX.Y ``` @@ -106,33 +103,22 @@ When starting development on a new minor release, the first step is to create a Then, run manifest generation - ``` + ```sh make generate ``` Commit your changes - ``` + ```sh Update manifests for release-vX.Y ``` Then, push your changes to the branch. - ``` + ```sh git push origin release-vX.Y ``` -### Setting up netlify - -1. On netlify create a new site using the `release-vX.Y` branch (You should at least have write access to this repo for site creation) - -1. Rename the randomly generated site name to follow the same naming convention as other releases (Ex: `calico-vX-Y`). - -1. Ensure that the site is generated properly by visiting site URL (Ex. https://calico-vX-Y.netlify.app/archive/vX.Y/). - -1. Cherry-pick the proxy rules commit created earlier to the latest production branch, as well as `master`. - This will make the candidate site docs available at `projectcalico.docs.tigera.io/archive/vX.Y/` (Note: the trailing slash) - ### Updating milestones for the new branch Once a new branch is cut, we need to ensure a new milestone exists to represent the next release that will be cut from the master branch. @@ -145,13 +131,13 @@ Once a new branch is cut, we need to ensure a new milestone exists to represent ### 4.a Create a temporary branch for this release against origin -1. Create a new branch based off of `release-vX.Y`. +1. Create a new branch `build-vX.Y.Z` based off of `release-vX.Y`. - ``` + ```sh git checkout release-vX.Y && git pull origin release-vX.Y ``` - ``` + ```sh git checkout -b build-vX.Y.Z ``` @@ -162,7 +148,7 @@ Once a new branch is cut, we need to ensure a new milestone exists to represent 1. Update manifests (and other auto-generated code) by running the following command in the repository root. - ``` + ```sh make generate ``` @@ -170,18 +156,20 @@ Once a new branch is cut, we need to ensure a new milestone exists to represent Then, add the newly created release note file to git. - ``` + ```sh git add release-notes/-release-notes.md ``` 1. Commit your changes. For example: - ``` + ```sh git commit -m "Updates for vX.Y.Z" ``` 1. Push the branch to `github.com/projectcalico/calico` and create a pull request. Get it reviewed and ensure it passes CI before moving to the next step. +1. If this is the first release from this release branch i.e. `vX.Y.0`, create a new Calico X.Y.x PPA in launchpad + ### 4.b Build and publish the repository in Semaphore To build and publish the release artifacts, find the desired commit [in Semaphore](https://tigera.semaphoreci.com/projects/calico), verify that all tests for that @@ -193,24 +181,9 @@ Wait for this job to complete before moving on to the next step. Follow [the tigera/operator release instructions](https://github.com/tigera/operator/blob/master/RELEASING.md). -### 4.d Build and publish OpenStack packages +### 4.d Publish the release on Github -1. Check out the release tag in the `projectcalico/calico` repository. - - ``` - git fetch origin --tags && git checkout vX.Y.Z - ``` - -1. In your environment, set `HOST` to the GCP name for binaries.projectcalico.org, `GCLOUD_ARGS` to the `--zone` and `--project` args needed to access that host, and `SECRET_KEY` to - the secret key for a GPG identity that you have uploaded to your Launchpad account. - -1. Establish GCP credentials so that gcloud with `HOST` and `GCLOUD_ARGS` can access binaries.projectcalico.org. - -1. Build OpenStack packages from the checked out commit. - - ``` - make -C release/packaging release-publish VERSION=vX.Y.Z - ``` +Go to the [Calico release page](https://github.com/projectcalico/calico/releases) and publish the draft release. ### 4.e Update the docs with the new version @@ -230,7 +203,7 @@ Follow [the tigera/operator release instructions](https://github.com/tigera/oper 1. Run the post-release checks. The release validation checks will run - they check for the presence of all the required binaries tarballs, tags, etc. - ``` + ```sh make VERSION=... FLANNEL_VERSION=... OPERATOR_VERSION=... postrelease-checks ``` @@ -238,6 +211,46 @@ Follow [the tigera/operator release instructions](https://github.com/tigera/oper 1. Kick off some e2e tests to test the contents of the release. +### Update API repository + +The `projectcalico/api` repository needs to be updated to stay in sync with the Calico API. + +**First**, ensure that you have [Github CLI tool](https://github.com/cli/cli#installation) + +1. Clone the API repository + + ```sh + git clone git@github.com:projectcalico/api.git + ``` + +1. Create or checkout the release branch `release-vX.Y`. + + For a major/minor release: + + ```sh + git checkout -b release-vX.Y && git push origin release-vX.Y + ``` + + For a patch release: + + ```sh + git checkout release-vX.Y && git pull origin release-vX.Y + ``` + +1. Update APIs by running the following command + + ```sh + make -f Makefile.local pr CALICO_GIT_REF=vX.Y.Z` + ``` + + This runs a script that clones `projectcalico/calico`, import the updated files and creates a PR. + + > NOTE: if an auto-api PR already exists for this version, + > it will print an error about the PR existing already. + > The existing PR still gets updated with changes + +1. Get the PR reviewed, approved and merged + # Release notes Release notes for a Calico release contain notable changes across Calico repositories. To write release notes for a given version, perform the following steps. @@ -246,7 +259,7 @@ Release notes for a Calico release contain notable changes across Calico reposit Use this URL to query for PRs, replacing `vX.Y.Z` with your desired version. - ``` + ```sh https://github.com/issues?utf8=%E2%9C%93&q=user%3Aprojectcalico+milestone%3A%22Calico+vX.Y.Z%22+ ``` @@ -258,7 +271,7 @@ Release notes for a Calico release contain notable changes across Calico reposit 1. Run the following command to collect all release notes for the given version. - ``` + ```sh make release-notes ``` @@ -271,23 +284,11 @@ Release notes for a Calico release contain notable changes across Calico reposit Consistent release note formatting is important. Here are some examples for reference: - - [Example release notes for a major/minor release](https://github.com/projectcalico/calico/blob/v3.1.0/_includes/v3.1/release-notes/v3.1.0-release-notes.md) - - [Example release notes for a patch release](https://github.com/projectcalico/calico/blob/7d5594dbca14cb1b765b65eb11bdd8239d23dfb3/_includes/v3.0/release-notes/v3.0.5-release-notes.md) + - [Example release notes for a major/minor release](https://github.com/projectcalico/calico/blob/v3.28.0/release-notes/v3.28.0-release-notes.md) + - [Example release notes for a patch release](https://github.com/projectcalico/calico/blob/v3.28.2/release-notes/v3.28.1-release-notes.md) 1. Add the generated file to git. - ``` + ```sh git add release-notes/ ``` - -# API Repository update - -The `projectcalico/api` repository needs to be updated to stay in sync with the Calico API. The following steps will ensure that: - -1. Ensure that you have the `gh` tool installed, configured, and authenticated. Instructions are here: https://cli.github.com/manual/ -1. Clone the repository: `git clone -b release-v3.29 git@github.com:projectcalico/api.git calico-api-v3.29` -2. `cd` into the repository and run the `pr` make target from `Makefile.local`: `make -f Makefile.local pr CALICO_GIT_REF=`. `CALICO_GIT_REF` should be the tag for this release, e.g. `CALICO_GIT_REF=v3.29.0` if that's the version you just released. -3. The script will clone the upstream repository (i.e. `projectcalico/calico`), import the updated files, commit them, and create a PR for them -7. Once this is done, it will output a URL for a PR, which you can then review and get approved. - -Note that if an auto-api PR already exists for this minor version, it will print an error about the PR existing already; this is fine, and the script will have updated the PR instead. Go to Github, find the PR manually, and review it to ensure everything looks correct, then have it merged. diff --git a/release/pkg/manager/calico/manager.go b/release/pkg/manager/calico/manager.go index 8ef8562ab95..b1976ac8458 100644 --- a/release/pkg/manager/calico/manager.go +++ b/release/pkg/manager/calico/manager.go @@ -751,6 +751,7 @@ Additional links: "-repository", r.repo, "-name", ver, "-body", releaseNote, + "-draft", ver, r.uploadDir(), }