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