Skip to content

Latest commit

 

History

History
82 lines (63 loc) · 4.07 KB

RELEASING.adoc

File metadata and controls

82 lines (63 loc) · 4.07 KB

Releasing Kiali

Kiali is released weekly on Fridays: a minor release every three weeks, and snapshots on the other weeks.

Sometimes, there are extraordinary releases which usually are z-stream releases (a.k.a. patch releases). Thought, in some cases there have been some minor releases out of schedule, which tend to be created to go with an upcoming Istio release.

The artifacts that are released are the following:

Tags and branches are also created in the Kiali’s GitHub repositories, as a reference for rebuilds (if needed) or as a base for z-stream releases.

How releases are generated?

Jenkins is used to automate the releases.

At high level, the kiali back-end and front-end are built and packaged into a container image that is published to Quay.io. If this process fails, the release does not go forward. Once the kiali server image is published, then the Kiali operator, the helm charts and the website are built and published (these three artifacts are built in parallel).

If you want to learn the details of the process, you can read the release scripts and its documentation. Start at the deploy/jenkins-ci/ directory of this repository. There is a README.md

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 could try to run the release process locally.

Honestly, because of the automated releases, this hasn’t been done for a while and it’s not recommended to directly try a manual release without first testing on alternate repositories. It’s unknown if the release scripts still work properly to release locally. What is known, is that you would need a working development setup (read the main README.adoc of this repository). For the release, Docker is required (podman does not work). Once you have a working development environment, these commands are supposed to generate a release of the Kiali server:

# RELEASE_TYPE can be: major, minor, patch, edge, snapshot.0, snapshot.1, snapshot.2, etc.
export RELEASE_TYPE="snapshot.1"
export GH_TOKEN={your_github_api_token}

# You must provide credentials with privileges to push to
# the kiali repositories.
docker login quay.io

cd $KIALI_SOURCES/kiali-ui
make -f Makefile.jenkins release

cd $KIALI_SOURCES/kiali
make -f deploy/jenkins-ci/Makefile release

These special Makefiles are helpers that were created in the past to assist in manually creating a release. That was useful when the only artifact that was being released was the Kiali server container image. But nowadays we also generate the kiali operator, the helm charts and the website, and there are no equivalent helper Makefiles to assist in creating a release of these artifacts. You will need to manually replay these Jenkins scripts:

Since this manual process is unknown to work, and it also involves manually replaying commands, it’s probably better to set up a development environment for the Jenkins pipeline and run the release from it. Read the deploy/jenkins-ci/README.md to learn how.