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.
When the release process is complete, a new DockerHub image will be available in the Kiali Docker Hub repo.
These actions are not performed by the release process. Please, do these actions manually before running the release process.
If you know that you’ll spend a considerable amount of time doing the release, create a new issue on JIRA detailing the release, and add sub-tasks if necessary.
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.
These actions are not performed by the release process. Please, do these actions manually after the release process finishes successfully.
Edit all issues in Awaiting Release state with Fix-Version:
-
Use this query https://issues.jboss.org/issues/?filter=12336798
-
Use Tools>Bulk Change>All XX issue(s)
-
Select all issues and press
Next -
Edit issues -
Change Fix Version/s>`Add to existing`>Pick the version to release>UnselectSend mail for this update>Next>Confirm
Transition all issues to Released:
-
Use this query https://issues.jboss.org/issues/?filter=12337486
-
Use Tools>Bulk Change>All XX issue(s)
-
Select all issues and press
Next -
Transition issues -
Released>Next -
Unselect
Send mail for this update>Next>Confirm
After that, close the release issues, and then, create a new Release in JIRA
for the next release.
Mark the current version as released, and create a new minor version: https://issues.jboss.org/projects/KIALI?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
There are no fixed steps for releasing a new version on the Istio installer, each release is kind of different.
This has been done a few times before, so they can be used as references:
Those PRs cover both the ansible-installer and the helm installer updates.
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.
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.
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 docker image integrating the back-end and the front-end is built and pushed to DockerHub
-
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)
-
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.
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:
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.
-
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.
-
-
Login to DockerHub
-
docker login docker.io
-
-
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.
-
-
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.
-
-
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).
-
The generated Docker image is published to kiali/kiali DockerHub repository. If you want to publish to another repository:
-
DOCKER_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
-