RELEASING.md

Releasing Kiali

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 Kiali Quay.io repository
• The Kiali operator container image, which is published to the Kiali operator Quay.io repository
• The OpenShift Service Mesh Console (OSSMC) plugin image, which is published to the OSSMC Quay.io repository
• 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.

Troubleshooting (WIP)

For troubleshooting, take a look to the following documentation.

How releases are generated?

The releases are generated by GitHub Actions pipelines. These pipelines run on every Kiali repository generating the artifacts previously mentioned:

• kiali
• kiali-operator
• openshift-servicemesh-plugin
• helm-charts
• kiali.io

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).

Generating a release locally (without automation)

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

Release pipelines design

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:
      target_branch: ${{ github.ref_name }}
      release_type: ${{ steps.release_type.outputs.release_type }}
      release_version: ${{ steps.release_version.outputs.release_version }}
      branch_version: ${{ steps.branch_version.outputs.branch_version }}
      next_version: ${{ steps.next_version.outputs.next_version }}
      quay_tag: ${{ steps.quay_tag.outputs.quay_tag }}
    steps:    
    
    ...
    
    - name: Log information
      run: |
        echo "Release type: ${{ steps.release_type.outputs.release_type }}"

        echo "Release version: ${{ steps.release_version.outputs.release_version }}"

        echo "Next version: ${{ steps.next_version.outputs.next_version }}"

        echo "Branch version: ${{ steps.branch_version.outputs.branch_version }}"

        echo "Quay tag": ${{ steps.quay_tag.outputs.quay_tag }}

  ...

  release:
    name: Release
    if: ${{ needs.initialize.outputs.release_type != 'skip' && ((github.event_name == 'schedule' && github.repository == 'kiali/kiali') || github.event_name != 'schedule') }}
    runs-on: ubuntu-20.04
    needs: [initialize, build_backend, build_frontend, integration_tests_backend, integration_tests_frontend]
    env:  
      RELEASE_VERSION: ${{ needs.initialize.outputs.release_version }}
      BRANCH_VERSION: ${{ needs.initialize.outputs.branch_version }}
      NEXT_VERSION: ${{ needs.initialize.outputs.next_version }}
      RELEASE_BRANCH: ${{ github.event.inputs.release_branch || github.ref_name }} 
      QUAY_TAG: ${{ needs.initialize.outputs.quay_tag }}
    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:

Initialize

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.

Release

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