diff --git a/content/docs/contributing/release-process.md b/content/docs/contributing/release-process.md index b772c59567..763876647d 100644 --- a/content/docs/contributing/release-process.md +++ b/content/docs/contributing/release-process.md @@ -225,7 +225,7 @@ page if a step is missing or if it is outdated. > This is only a temporary change to allow you to update the branch. > [Prow will re-apply the branch protection within 24 hours](https://docs.prow.k8s.io/docs/components/optional/branchprotector/#updating). -5. Create the tag for the new release locally and push it upstream: +5. Create the tag for the new release locally and push it upstream (starting the cert-manager build): ```bash RELEASE_VERSION=v1.8.0-beta.0 @@ -240,6 +240,10 @@ page if a step is missing or if it is outdated. permission, you will have to open a PR to merge master into the release branch), and wait for the PR checks to become green. + For recent versions of cert-manager, the tag being pushed will trigger a Google Cloud Build job to start, + kicking off a build using the steps in `gcb/build_cert_manager.yaml`. Users with access to + the cert-manager-release project on GCP should be able to view logs in [GCB build history](https://console.cloud.google.com/cloud-build/builds?project=cert-manager-release). + 6. Generate and edit the release notes: 1. Use the following two tables to understand how to fill in the four @@ -322,22 +326,27 @@ page if a step is missing or if it is outdated. 4. **(final release only)** Check the release notes include all changes since the last final release. -7. Run `cmrel makestage`: +7. Check that the build is complete and send Slack messages about the release: + + 1. For recent versions of cert-manager, the build will have been automatically + triggered by the tag being pushed earlier. You can check if it's complete on + the [GCB Build History](https://console.cloud.google.com/cloud-build/builds?project=cert-manager-release). - 1. In this example we stage a release using the `v1.8.0-beta.0` git ref: + 2. If you're releasing an older version of cert-manager (earlier than 1.10) then the automatic build + will failed because the GCB config for that build wasn't backported. + In this case, you'll need to trigger the build manually using `cmrel`, which takes about 5 minutes: ```bash # Must be run from the "cert-manager/release" repo folder. cmrel makestage --ref=$RELEASE_VERSION ``` - This step takes ~5 minutes. It will build all container images and create + This build takes ~5 minutes. It will build all container images and create all the manifest files, sign Helm charts and upload everything to a storage bucket on Google Cloud. These artifacts will then be published and released in the next steps. - 2. While the build is running, send a first Slack message to - `#cert-manager-dev`: + 3. In any case, send a first Slack message to `#cert-manager-dev`:

Releasing 1.2.0-alpha.2 🧵 @@ -345,13 +354,12 @@ page if a step is missing or if it is outdated.

🔰 Please have a quick look at the build log as it might contain some unredacted - data that we forgot to redact. We try to make sure the sensitive data is + data that we forgot to hide. We try to make sure the sensitive data is properly redacted but sometimes we forget to update this.

3. Send a second Slack message in reply to this first message with the - Cloud Build job link that `cmrel` displayed in "View logs at". For - example, the message would look like: + Cloud Build job link. For example, the message might look like:

Follow the cmrel makestage build: https://console.cloud.google.com/cloud-build/builds/7641734d-fc3c-42e7-9e4c-85bfc4d1d547?project=1021342095237