Skip to content

Latest commit

 

History

History
164 lines (127 loc) · 7.58 KB

RELEASING.adoc

File metadata and controls

164 lines (127 loc) · 7.58 KB
Raw

Releasing Kiali

Kiali is released weekly on Fridays: a minor release every three weeks, and snapshots on the other weeks. A Jenkins instance is used to automate the releases.

If you need to make an extraordinary release, please ask to a member of the QE team to trigger the release for you. Alternatively, ask the QE team for access to the Jenkins instance and trigger the release by yourself.

If you don’t have access to Jenkins, or want to test the release locally, you can run it on your machine.

Currently, the Pipeline supports major, minor, snapshot (end-of-week) and patch releases. Minor and snapshot releases will release the back-end and the front-end together. Patch releases have the option to omit releasing the UI and, instead, use the latest UI in the final package.

Edge-snapshots (or snapshots after merged PRs) are also handled in the Pipeline.

Finished product

When the release process is complete, a new container image will be available in the Kiali Quay.io repository.

Actions before creating a release

These actions are not performed by the release process. Please, do these actions manually before running the release process.

Updating Docs

Make sure that the Getting Started document of the website is up to date and works with the new version.

The doc sources are in the kiali/kiali.io repository. Update the document, and create a PR.

Actions after creating a release

These actions are not performed by the release process. Please, do these actions manually after the release process finishes successfully.

Send out notifications

Finally, we just need to send the notifications to create awareness of the new release:

  • Post an email about the release on our Mailing List. This is done automatically if you are doing a minor or major release.

  • Send a message on our channel at Freenode, #kiali.

  • Post a message on our twitter, @KialiProject. If you don’t know who’s responsible for the account, ask on IRC.

Release process of the Jenkins Pipeline

The Pipeline uses the Jenkinsfile located at deploy/jenkins-ci/Jenkinsfile in the kiali/kiali repository.

The Pipeline performs the following actions to do the release:

  • Checkouts the code of, both, the back-end and the front-end

  • Builds the back-end and the front-end

  • Run tests for back-end and front-end

  • If all tests pass:

    • The front-end is released to NPM

    • A container image integrating the back-end and the front-end is built and pushed to Quay.io

    • Tags for the new releases are created

    • If a minor release was done, master branches are prepared for the next version and a version branches named of the form vX.Y are created

    • If a patch release was done, vX.Y branches are prepared for the next version

    • If a major release was done, versions in vX.Y branches are promoted (-snapshot suffix is removed)

Running the release process locally

If you don’t have access to the Jenkins instance or the release process through Jenkins doesn’t suit your needs, you may want to run the release process locally.

Requirements

You must have write permissions to the kiali public GitHub repository in order to be able to push the tags. You will also need an DockerHub account that is able to publish to the DockerHub kiali/kiali repository.

You will need a working dev environment (git, golang, docker, make, etc). You will also need the following tools available in your $PATH:

  • semver shell utility - used to update version numbers

  • npm - to download and package kiali-ui

  • curl - because the release process places PRs using the GitHub API

If the release process can’t update the kiali repositories, a PR is automatically created if you provide a GitHub Token for your account.

It’s assumed that you are running the release process in you fork of the kiali/kiali GitHub repository.

Making the release

  1. Make a release of the front-end, if needed

    • Please, follow the releasing guide for the front-end

    • You can omit this step if there is no need to release the front-end. Kiali will be released using the specified version of the front-end.

  2. Login to Quay.io

    • docker login quay.io

  3. Checkout the code that you want to release:

    • git checkout branch_to_release (usually, you should release "master")

    • Be advised that the release process will commit changes locally.

    • PATCH RELEASES: you need to check out the minor branch (vX.Y) and cherry-pick all commits that need to go into the patch release. You should then push these new commits to the vX.Y branch. At this point, you can continue the release build.

  4. The release process may need to create a PR to prepare the code for the next version. A GitHub token is required to create the PR:

    • export GH_TOKEN={your_github_token}

    • Optional: If a token is not provided, a branch is created in your fork of the code, if needed. Then, you can place the PR manually.

  5. Run the release process:

    • CONSOLE_VERSION="{ui-version}" make -f deploy/jenkins-ci/Makefile release

In the last step, you can omit the CONSOLE_VERSION variable. However, it is very highly recommended that you specify the version of the UI to package. If you released kiali-ui (step 1), you should specify the version you just released. Else, you should specify whatever version you need packaged. If you don’t specify a kiali-ui version, the console version specified in the main Makefile will be downloaded from NPM and packaged in the release. If the main Makefile specifies latest as the console version, the latest version published in NPM will be used, which is not necessarily the latest released version (most likely it will be a snapshot).

By default, it’s assumed that you are doing a minor release. If want to do another type of release, you can run the release process specifying the RELEASE_TYPE variable. Valid values are "major", "minor", "patch", "edge" and "snapshot.X". For example:

  • RELEASE_TYPE="snapshot.1" make -f deploy/jenkins-ci/Makefile release

Note: The process will adjust the version string as needed, according to the type of release. Please, don’t try to adjust the version string (i.e. don’t change the version in the Makefile).

Available options

  • The generated container image is published to kiali/kiali Quay.io repository. If you want to publish to another repository:

    • QUAY_NAME="{repository}" make -f deploy/jenkins-ci/Makefile release`

  • In major, minor or patch mode, the release process updates or creates a version branch in the kiali-ui repository (the branch name is like "vMAJOR.MINOR"). You can omit the creation of this branch:

    • OMIT_VERSION_BRANCH=y make -f deploy/jenkins-ci/Makefile release

  • In major, minor or patch mode, the release process may create a branch in your fork of the repository with the required changes to prepare the code for the next release. The branch is created if it isn’t possible to push to the kiali-ui repository. By default, the name of the branch is prepare_next_version. If you want to customize the name of the branch:

    • BUMP_BRANCH_ID={branch_name} make -f deploy/jenkins-ci/Makefile release