Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: releasing.md

<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Table of Contents generated with - - - - - - - - - <!-- END doctoc generated TOC please keep comment here to allow auto update --> If you're new to using GKE or are new to the release team, you'll need to authenticate to GCP first. and then execute the following commands, substituting your Kubeflow release team account for `your-account@yourdomain.org` (if you aren't a member of `release-team@kubeflow.org`, ask to be added): ``` gcloud config set account your-account@yourdomain.org gcloud auth login ``` This will open your browser to authenticate you. Then you can proceed as follows: ``` gcloud config set project kubeflow-releasing gcloud container clusters get-credentials kubeflow-releasing --zone us-central1-a --project kubeflow-releasing ``` Need to join before you can publish a release. Create an issue in Label the issue with `priority p0` Label the issue with `kind process` Example: Announce the release in `#release` channel in kubeflow.slack.com. Also please link the tracking issue to the announcement. A release branch should be substantially feature complete with respect to the intended release. Code that is committed to `master` may be merged or cherry-picked on to a release branch, but code that is directly committed to the release branch should be solely applicable to that release (and should not be committed back to master). In general, unless you're committing code that only applies to the release stream (for example, temporary hotfixes, backported security fixes, or image hashes), you should commit to `master` and then merge or cherry-pick to the release branch. You can create a release branch via the GitHub UI. Releaser needs to do the following to the components listed: Cut a release branch if necessary (during major release) Enable periodic tests if creating a release branch to components. Update `prow_config.yaml` if necessary. Make sure newly added periodic tests are green. Build and push docker images to `gcr.io/kubeflow-images-public` Update kustomize manifests on If you aren't already working on a release branch (of the form `v${MAJOR}.${MINOR}-branch`, where `${MAJOR}.${MINOR}` is a major-minor version number), then create one. Release branches serve several purposes: They allow a release wrangler or other developers to focus on a release without interrupting development on `master`, they allow developers to track the development of a release before a release candidate is declared, they allow sophisticated users to track the development of a release, and they simplify backporting critical bugfixes to a patchlevel release particular release stream (e.g., producing a `v0.1.1` from `v0.1-branch`), when appropriate. Most applications should be configured to be built continuously from their release branch and the relevant kustomize manifests to be updated () Follow the following steps: Add a `version` for the new release to Set the `version` for each repository to point to the release branch e.g. vX.Y for kubeflow/kubeflow Set the tag associated with this version Merge the PR. Once the PR is merged Tekton Pipelines will be submitted to automatically build the docker images and open PRs to update the kustomzie manifests Approve the PRs updating the kustomize manifests to use the new images. Once the release branch is cut we need to enable periodic tests on the release branch and setup a Modify to define a new periodic prow

Modify Copy the entries for the most recent release branch and change it to the new release branch Submit a PR with the above changes. After you have completed the steps to release the components, it's time for you to wrap up the release and send to the community for review. Create a release branch (when releasing major release) in Update versions tag in descripter for all application: A KfDef config file is used to pin the version for the repos we use. Example file: Add the file to in the release branch. Starting with kubeflow/manifests#778 On the master branch Define a kustomize overlay: `source/vX.Y.Z` For every kfdef add a patch that overrides the repo spec and version in the KFDef Look at the existing config Run `hack/buildkfdefspec.py` to generate KFDef YAMLs in `kfdefs/` Check in all modified files On the vX.Y-branch branch Cherry pick the changes from above You can use the to automate uploading artifacts. Alternatively you can use the UI. Get aktau/github-release ``` go get github.com/aktau/github-release ``` You'll need a GitHub token to authenticate to GitHub see Checkout the release commit ``` git checkout ${COMMIT} ``` TODO(jlewi): Ideally we automate the builds and publish them e.g. to a GCS bucket on postsubmit. Build kfctl for linux and mac ``` cd bootstrap TAG=v0.5.0-rc.1 make push-to-github-release ``` Set the tag to be the correct version for the tag. The main Kubeflow website at points to the latest change of for most recent Kubeflow and individual components' guides. For each minor (vX.Y) release, we also publish a corresponding version of the website. Each version of the website is generated from a separate of the `kubeflow/website` repository. And you can view versioned documentation from the website's . The naming convention is as follows: The site at `vX-Y.kubeflow.org` points to the release at vX.Y-branch. For example, the is maintained in the branch called . Our typical process when getting ready to do a minor release vX.Y (i.e. going from vX.Y to vX.Z); this process doesn't apply for patch releases. Follow the to create a release branch for vX.Y. Follow the to set up a versioned documentation on Kubeflow website. Develop vX.Z docs on the master branch Docs for the master branch should be available on Follow the to mark the docs on the vX.Y branch as archived Other guides: If we ever need to update the default website version, follow the below to point to the desired branch. There are which have been out-of-date, but keeping a link here in case we need it in the future. <a id="create-website-branch"></a> Create a new section (vX.Y) for dropdown in `config.toml` (). Update the shortcode that holds the latest Kubeflow version: Edit . Update the version number. For example, if the upcoming release is Kubeflow v0.7.0: ``` v0.7.0 ``` Create a new version branch under the . The branch name should have the following format: `v${MAJOR}.${MINOR}-branch`, where `v${MAJOR}.${MINOR}` is the Kubeflow version. For example, `v0.6-branch`. (You can create a branch on the GitHub UI. See the GitHub guide to [creating branches in your repo](https://help.github.com/en/articles/creating-and-deleting-branches-within-your-repository).) In `vX.Y-branch`, change `version_menu`, `version` and `githubbranch` to the corresponding vX.Y branch value (). Netlify should auto deploy this branch once its created (see ) Netlify publishes the website on `${BRANCHNAME}--competent-brattain-de2d6d.netlify.com` Note* Periods in the branch name are automatically replaced with dash names

`v0.7-branch` is https://v0-7-branch--competent-brattain-de2d6d.netlify.com You can check under deploys to see if Netlify deployed it If no deploys show up you can push a commit to the branch to trigger a deploy <a id="deploy-to-netlify"></a> Note: Contact with the link to this section when we want to cut a new version for Kubeflow website in Netlify. Admins use Netlify manage branches for Kubeflow website hosting and update the default branch if needed. Kubeflow Admins need permission to Netify project, and `kubeflow-dns` GCP project. Set up DNS for the new site: In , select the `kubeflow.org` zone. Create a new CNAME record set for `v${MAJOR}-${MINOR}-branch.kubeflow.org`, pointing to the new site (`something-something.netlify.com`), with TTL of 5 minutes. Canonical name: ${BRANCHNAME}--competent-brattain-de2d6d.netlify.com. (Example: v0-7-branch--competent-brattain-de2d6d.netlify.com) Note: The version format in the URL is different from that in the GitHub branch name! The URL has a dash between major and minor version. For example: `v0-6.kubeflow.org`. Wait for the DNS record to propogate. You can use `nslookup` to check this. ``` nslookup v0-7-branch.kubeflow.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: v0-7-branch.kubeflow.org canonical name = v0-7-branch--competent-brattain-de2d6d.netlify.com. Name: v0-7-branch--competent-brattain-de2d6d.netlify.com Address: 206.189.73.52 Name: v0-7-branch--competent-brattain-de2d6d.netlify.com Address: 2604:a880:2:d0::21e9:b001 ``` At this point you should be able to access the branch at `https://${BRANCHNAME}.kubeflow.org` but you will get an `NET::ERRCERTCOMMONNAMEINVALID` SSL certificate error You should be able to proceed through to see the site but you may need to be incognito mode File a support request with Netlify to fix the SSL certificate The (Step #4) say to file a support request to fix the domain to work with branch deploys when using external DNS. You can use this to describe the SSL certificate update request. We use external DNS (Cloud DNS); we do not use Netlify DNS We have an A record to redirect kubeflow.org to Netlify Ref original setup of Netflix We use CNAME records to map `v${MAJOR}-${MINOR}-branch.kubeflow.org` to `{BRNACHNAME}competent-brattain-de2d6d.netlify.com` <a id="archive"></a> When the website branch exists for the previous version of the docs (vX.X) and www.kubeflow.org has released a new version (vX.Y), we must mark the docs for vX.X as being archived. On the branch corresponding to vX.X In the `config.toml` for the version branch, set the `archived_version` parameter to `true`: ``` archived_version = true ``` This will add a banner at the top of all the docs letting users know they are viewing an archived version. Create a PR for the above update, setting the base branch in the PR to the vX.X's version branch (not master). Then request a review and merge the PR. <a id="update-kubeflow-org"></a> In Netlify, select `www.kubeflow.org` site: https://app.netlify.com/sites/competent-brattain-de2d6d/overview. Select `Site settings` Select `Build & deploy` Find the section called `Branches` Click `Edit settings` Change the `Production branch` to the branch to surface by default. (Optional) Redeploy both branches You can trigger a redeploy by pushing commits to the branches NB: release votes will take effect beginning with the 0.2 release stream; the specifics of the release vote policy will be finalized before then. A release candidate that has passed a community vote should be tagged as an official release. This simply involves creating another tag for the commit pointed to by the RC tag and pushing this to GitHub. Tags that resemble version numbers or release candidates should automatically show up in the "releases" tab for the repo, but you can use the "draft a release" feature to add release notes.