-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Description
Modified version of #31627 (from 1.10)
This issue aims to track all steps needed to prepare the release 1.11 branches/builds.
This issue was created early to help document the steps using some new automation (I hope) as well as any ordering changes, etc. Please update/add additional steps taken here so we can document for future releases.
See #24473 for steps used for the release 1.7 branch cutting; (note: 1.8 will be more relevant, see #27993). Note that was before automation, but does have pointers to PRs to see what some of the steps did. Note that the actual coding steps done by the automation steps are left in this issue for reference only. You only need to run the automated steps, and not the individual instructions. Also note that the reference steps may be INCOMPLETE as the automation is updated, not necessarily the reference steps.
For now, the code to run is in https://github.com/istio/release-builder master branch. From within that branch, one can do a make shell
and then within the shell run REPO_ORG=myorg STEP=x ./release/branch.sh
(you can update the STEP in the trigger-branch
file and not set it manually). This generates the changes for review (trygit status
or git diff
). Adding DRY_RUN=false will cause the PRs to be created in the REPO_ORG.
Note that the automated steps 3 and on require the new release's branch in the various repos which are created by automated step 2.
-
Set up release manager team - Make sure the new team has write access to the repositories. (done here and here)
-
Send an announcement on Discuss pre-announcing branch cut (adding, but are branch cut notifications needed and where?)
-
Send an announcement on Discuss announcing the start of branch cut and to stop merging of PRs (adding, but are branch cut notifications needed and where?)
-
Build new base images:
1.12-dev.0
. Runtools/build-base-images.sh
. You may also update the1.11-dev
image to fix existing CVEs, although new code should create these automatically when you try the first 1..11 build. (reach out to @howardjohn or possibly @brian-avery) -
(Automation step=1) Update dependencies. This must be done before branching so that PRs can be easily backported later.
- Check if
github.com/envoyproxy/go-control-plane
dependency needs to be updated (to master?). Ask Kuat. - Run the following command in istio/istio
UPDATE_BRANCH=master ./bin/update_deps.sh; make gen
- Merge PR in istio/istio. Wait for it to complete.
- Check if
-
(Automation step=2) (new step because we are waiting on prior change to master before branching) Create a
release-1.11
branch in every Istio repo - run commandsexport org=xyz ; export repo=xyz ; (git clone git@github.com:${org}/${repo}.git && cd $repo && git checkout -b release-1.11 && git push --set-upstream origin release-1.11)
.- istio/istio
- istio/pkg
- istio/api
- istio/proxy
[ ] istio/envoyNot needed - we are using upstream envoyproxy/envoy- istio/client-go
- istio/tools
- istio/common-files
- istio/gogo-genproto
- istio/release-builder
- istio/enhancements
- Explicitly skipped: istio-releases/pipeline, istio/tests, istio/istio.io, istio/test-infra
- No PRs to merge as the new branches were created by automation
-
Set up branch protection. Modify prow/config.yaml in test-infra to add release manages as owners for a branch.
-
[ ] (not automated) Adjust istio/proxy to correct version of istio/envoy. Requires istio/envoy to be set up for new release. We point to envoyproxy directly now?, so this step may be a little different. I don't think envoy has cut their new version yet, so maybe point at theirNot needed - we are using upstream envoyproxy/envoymain branch
. -
(Automation step=3) (doesn't work locally, appears to need credential to add a tag to an existing build-tools image)(new step because this might need to be done separately) Set up prow on release branches
go run generate.go branch 1.11
(Note: Needed to run postsubmit in next step) (Contact Googler or ping in #test-and-release slack channel for help). -
(Automation step=4) (new step since we want the automation from prior step to actually create the image after PR merges)
- Updates istio/tools to build new release-1.11 build image (update BRANCH in docker/build-tools/build-and-push.sh. PR postsubmit will create new container images whose name will be used in the next step) eg: [release-1.9] update build image for 1.9 tools#1397
- Update common-files in new release. You first have to manually update the common/Makefile.common.mk update-common target to point to the new release (but not in common-files). The next step will cause the prow automation to actually call
make update-common
in these repos to do the actualmake update-common
against the new common-files release branch- istio/common-files - skipped. Covered in next step
- istio/istio
- istio/pkg
- istio/api
[ ] istio/envoyNot needed, we didn't branch envoy for 1.11- istio/client-go
- istio/gogo-genproto
- istio/proxy
- istio/release-builder
- istio/tools
- Update
CODEOWNERS
to contain only the release managers for this release. Command:export org=xyz ; export repo=xyz ; (git clone git@github.com:${org}/${repo}.git && cd $repo && git checkout release-1.11 && git checkout -b release-1.11-codeowners && echo '* @istio/release-managers-1-11' > CODEOWNERS && git add CODEOWNERS && git commit -m 'Set release managers as CODEOWNERS for release-1.11' && git push --set-upstream origin release-1.11-codeowners)
.- istio/istio
- istio/pkg
- istio/api
[ ] istio/envoyNot needed, we didn't branch envoy for 1.11- istio/proxy
- istio/client-go
- istio/tools
- istio/common-files
- istio/gogo-genproto
- istio/release-builder
- istio/enhancements
- Stop publishing
latest
tags - Update istio/release-builder branch changes from
master
to new release in build.sh, publish.sh and manifests.
-
Merge PRs from STEP 4. Wait for the new build images to be created at https://gcr.io/istio-testing/build-tools.
-
(Automation step=5) (new step since we need image from prior step) Update istio/common-files to set release-1.11 build image (Update the UPDATE_BRANCH in files/common/Makefile.common.mk to be the new release name, and IMAGE_VERSION in files/common/scripts/setup_env.sh to be the new build image from prior step (found at https://gcr.io/istio-testing/build-tools)
-
Merge PR from STEP 5. Wait until step 5 PR merges and all the postsubmit generated PRs (to update common files in repos) merge.
Additional steps that still need automation (if possible)
-
Add new label: cherrypick/release-1.11: Add cherrypick label for 1.11 bots#386
-
Create a 1.12 milestone: Add 1.12 milestone bots#387
-
Bump master to version 1.12
- Update Istio: 1.11.0 to 1.12.0, 1.11-dev to 1.12-dev, etc: Bump master to 1.12 #34052
-
Send an announcement on Discuss announcing branch cut complete and PRs can be merged again (adding, but are branch cut notifications needed and where?)
-
Add release lock for release 1.11 in master branch of API repo. See https://github.com/istio/api/blob/master/scripts/check-release-locks.md
-
Publish a beta release (from https://docs.google.com/document/d/1ilwz-HGSeiRDCFwP5rm-5d_UY6OOYL_nflx7bNggek0/edit#heading=h.qex63c29z2to, builds on release branch are labeled
beta
. Updating below names to reflect that.- Trigger a 1.11 beta.0 build
- Some verification to verify build is good
- Publish a 1.11 beta.0 release
-
Send an announcement on Discuss announcing availability of beta. May wait and add something about starting the first round of community testing. (Done in Slack)
-
Ask istio.io team to run job to update to use the 1.11 branch (probably @ericvn)
-
Run the long-running tests on the dev builds (I asked Xinnan Wen on Slack)