Project: Kiali (Observability and Analysis / Observability)
File: RELEASING.md

Kiali releases a minor version every 3 weeks and eventually, if required, patch releases (z-stream) are also released. The artifacts that are released are the following: The Kiali server container image, which is published to the The Kiali operator container image, which is published to the The OpenShift Service Mesh Console (OSSMC) plugin image, which is published to the Helm charts for deploying the Kiali operator or the Kiali server via the Helm CLI, published to https://kiali.org/helm-charts/ The website that is published on https://kiali.io 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. For troubleshooting, take a look to the following . The releases are generated by GitHub Actions pipelines. These pipelines run on every Kiali repository generating the artifacts previously mentioned: The pipelines are scheduled to run on every Monday detecting if a released is needed (on every Sprint ending a release will be generated). Also, they can be started manually filling some parameters required by the pipeline (release type, branch name and image name). Although it is not recommended, in case of any issue with GitHub Actions, following the steps that the releases pipelines are executing should be enough to generate a release. As prerequisites, the user would require: Credentials with permissions to push images on the Kiali organization in Quay.io Credentials with permissions to administrate the Kiali GitHub repositories The following is an example of the anatomy of a release pipeline: ``` name: Release on: schedule: cron: '00 7 MON' workflow_dispatch: inputs: release_type: description: Release type required: true default: "auto" type: choice options: minor patch release_branch: description: Branch to release required: true default: master type: string quay_repository: description: Quay repository type: string default: quay.io/kiali/kiali required: true jobs: initialize: name: Initialize runs-on: ubuntu-20.04 outputs: targetbranch: ${{ github.refname }} releasetype: ${{ steps.releasetype.outputs.release_type }} releaseversion: ${{ steps.releaseversion.outputs.release_version }} branchversion: ${{ steps.branchversion.outputs.branch_version }} nextversion: ${{ steps.nextversion.outputs.next_version }} quaytag: ${{ steps.quaytag.outputs.quay_tag }} steps: ... name: Log information run: | echo "Release type: ${{ steps.releasetype.outputs.releasetype }}" echo "Release version: ${{ steps.releaseversion.outputs.releaseversion }}" echo "Next version: ${{

}}" echo "Branch version: ${{ steps.branchversion.outputs.branchversion }}" echo "Quay tag": ${{ steps.quaytag.outputs.quaytag }} ... release: name: Release if: ${{ needs.initialize.outputs.releasetype != 'skip' && ((github.eventname == 'schedule' && github.repository == 'kiali/kiali') || github.event_name != 'schedule') }} runs-on: ubuntu-20.04 needs: [initialize, buildbackend, buildfrontend, integrationtestsbackend, integrationtestsfrontend] env: RELEASEVERSION: ${{ needs.initialize.outputs.releaseversion }} BRANCHVERSION: ${{ needs.initialize.outputs.branchversion }} NEXTVERSION: ${{ needs.initialize.outputs.nextversion }} RELEASEBRANCH: ${{ github.event.inputs.releasebranch || github.ref_name }} QUAYTAG: ${{ needs.initialize.outputs.quaytag }} steps: ... ``` By design, the release pipelines can be triggered manually and also are scheduled to trigger on every Monday. When triggering manually, some parameters will be required, these are the inputs to the pipeline and every pipeline declares default values. When the pipeline is triggered automatically, it will detect if it needs to publish the release or not. Note: In the past, we ran the release pipeline every Monday using a cron job, then the snapshots or the minor release were created. It is the same with these new pipelines - we need to run the job every Monday (the GitHub Actions cron does not support running, for example, every 3 weeks). But we have now removed the building/releasing of weekly snapshots. Because weekly snapshots are no longer released, there is not much to do the first two weeks of our sprint (the pipeline will simply skip doing any release those first two weeks). On the third week of the sprint, the cron will fire on Monday, and at that time it will create a minor release. Each pipeline can have several jobs, and it will depend on the application, but there are common jobs that will be present on all the release pipelines: This job is used to gather the inputs, and use them to produce outputs for the pipeline to use, for example: Release type Release version Next version Quay tag This job also logs the variables to facilitate the troubleshooting of a pipeline. This job is used to generate all the required actions and assets to generate the release. This job will use some secrets to: Create branches, tags and releases on the GitHub repository GH_TOKEN Push images to the Quay repository QUAY_USER QUAY_PASSWORD