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:
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 documentation.
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 Friday 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:
The following is an example of the anatomy of a release pipeline:
name: Release
on:
schedule:
- cron: '00 19 * * FRI'
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 Friday.
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 Friday 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 Friday (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 Friday, 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:
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:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。