github.com/kiali/kiali@v1.84.0/RELEASING.md (about) 1 # Releasing Kiali 2 3 Kiali releases a minor version every 3 weeks and eventually, if required, patch releases (z-stream) are also released. 4 5 The artifacts that are released are the following: 6 7 * The Kiali server container image, which is published to the [Kiali Quay.io repository](https://quay.io/repository/kiali/kiali?tab=tags) 8 * The Kiali operator container image, which is published to the [Kiali operator Quay.io repository](https://quay.io/repository/kiali/kiali-operator?tab=tags) 9 * The OpenShift Service Mesh Console (OSSMC) plugin image, which is published to the [OSSMC Quay.io repository](https://quay.io/repository/kiali/ossmconsole?tab=tags) 10 * Helm charts for deploying the Kiali operator or the Kiali server via the Helm CLI, published to https://kiali.org/helm-charts/ 11 * The website that is published on https://kiali.io 12 13 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. 14 15 ## Troubleshooting (WIP) 16 17 For troubleshooting, take a look to the following [documentation](./.github/troubleshooting.md). 18 19 ## How releases are generated? 20 21 The releases are generated by GitHub Actions pipelines. These pipelines run on every Kiali repository generating the artifacts previously mentioned: 22 23 * [kiali](https://github.com/kiali/kiali/actions/workflows/release.yml) 24 * [kiali-operator](https://github.com/kiali/kiali-operator/actions/workflows/release.yml) 25 * [openshift-servicemesh-plugin](https://github.com/kiali/openshift-servicemesh-plugin/actions/workflows/release.yaml) 26 * [helm-charts](https://github.com/kiali/helm-charts/actions/workflows/release.yml) 27 * [kiali.io](https://github.com/kiali/kiali.io/actions/workflows/release.yaml) 28 29 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). 30 31 ## Generating a release locally (without automation) 32 33 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. 34 35 As prerequisites, the user would require: 36 37 * Credentials with permissions to push images on the Kiali organization in Quay.io 38 * Credentials with permissions to administrate the Kiali GitHub repositories 39 40 ## Release pipelines design 41 42 The following is an example of the anatomy of a release pipeline: 43 44 ``` 45 name: Release 46 47 on: 48 49 schedule: 50 - cron: '00 7 * * MON' 51 52 workflow_dispatch: 53 inputs: 54 release_type: 55 description: Release type 56 required: true 57 default: "auto" 58 type: choice 59 options: 60 - minor 61 - patch 62 release_branch: 63 description: Branch to release 64 required: true 65 default: master 66 type: string 67 quay_repository: 68 description: Quay repository 69 type: string 70 default: quay.io/kiali/kiali 71 required: true 72 73 jobs: 74 initialize: 75 name: Initialize 76 runs-on: ubuntu-20.04 77 outputs: 78 target_branch: ${{ github.ref_name }} 79 release_type: ${{ steps.release_type.outputs.release_type }} 80 release_version: ${{ steps.release_version.outputs.release_version }} 81 branch_version: ${{ steps.branch_version.outputs.branch_version }} 82 next_version: ${{ steps.next_version.outputs.next_version }} 83 quay_tag: ${{ steps.quay_tag.outputs.quay_tag }} 84 steps: 85 86 ... 87 88 - name: Log information 89 run: | 90 echo "Release type: ${{ steps.release_type.outputs.release_type }}" 91 92 echo "Release version: ${{ steps.release_version.outputs.release_version }}" 93 94 echo "Next version: ${{ steps.next_version.outputs.next_version }}" 95 96 echo "Branch version: ${{ steps.branch_version.outputs.branch_version }}" 97 98 echo "Quay tag": ${{ steps.quay_tag.outputs.quay_tag }} 99 100 ... 101 102 release: 103 name: Release 104 if: ${{ needs.initialize.outputs.release_type != 'skip' && ((github.event_name == 'schedule' && github.repository == 'kiali/kiali') || github.event_name != 'schedule') }} 105 runs-on: ubuntu-20.04 106 needs: [initialize, build_backend, build_frontend, integration_tests_backend, integration_tests_frontend] 107 env: 108 RELEASE_VERSION: ${{ needs.initialize.outputs.release_version }} 109 BRANCH_VERSION: ${{ needs.initialize.outputs.branch_version }} 110 NEXT_VERSION: ${{ needs.initialize.outputs.next_version }} 111 RELEASE_BRANCH: ${{ github.event.inputs.release_branch || github.ref_name }} 112 QUAY_TAG: ${{ needs.initialize.outputs.quay_tag }} 113 steps: 114 115 ... 116 117 ``` 118 119 By design, the release pipelines can be triggered manually and also are scheduled to trigger on every Monday. 120 121 When triggering manually, some parameters will be required, these are the inputs to the pipeline and every pipeline declares default values. 122 123 When the pipeline is triggered automatically, it will detect if it needs to publish the release or not. 124 125 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. 126 127 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: 128 129 #### Initialize 130 131 This job is used to gather the inputs, and use them to produce outputs for the pipeline to use, for example: 132 133 * Release type 134 * Release version 135 * Next version 136 * Quay tag 137 138 This job also logs the variables to facilitate the troubleshooting of a pipeline. 139 140 #### Release 141 142 This job is used to generate all the required actions and assets to generate the release. 143 144 This job will use some secrets to: 145 146 * Create branches, tags and releases on the GitHub repository 147 * GH_TOKEN 148 * Push images to the Quay repository 149 * QUAY_USER 150 * QUAY_PASSWORD 151 152