Improve the release process for the radix-operator.

[emirgens]

Using helm-charts without a proper version connection is troublesome.

Look into new ways of releasing this component.

Start using release versions which will build.

DoD
Tag, Release and chart version are connected
To make it possible to rollback

If you run version x of Helm you are sure it is version y of the app

[Richard87]

I have tested the following which I think might be a good solution for us:

Prod Service version: ">=1.0.0 < 2.0.0"
Dev service version: ">= 1.0.0-0 < 2.0.0-0"

Prod release is tagged with 1.X.X
Dev release is tagged with 1.X.X-nightly.TIMESTAMP

Interesting discussion: fluxcd/flux2#1298

Helm Github steps:

- name: Update helm chart
  id: update
  working-directory: infrastructure
  run: |
    yq -i '.version = "${{ steps.read.outputs.version }}"' Chart.yaml
    yq -i '.appVersion = "${{ steps.read.outputs.version }}"' Chart.yaml

- name: Helm Login
  run: |
    helm registry login happydogsprod.azurecr.io \
      --username helmuser \
      --password ${{secrets.HELM_REPO_SECRET}}

- name: package & push
  working-directory: infrastructure
  run: |
    helm package .
    helm push appname-${{ steps.read.outputs.version }}.tgz oci://repository.azurecr.io/helm

[Richard87]

I see we used to push HelmCharts to ACR, does anyone remember why we stopped?

[Richard87]

We should also have 1 helm chart that will release

• Radix Operator
• Radix Web Console
• Radix API
• Radix Github Webhook

Which also mean API, Console and Github Webhook should be build and deployed by github/flux, not by radix

[Richard87]

Chart

• Version: 1.0.1.6
• Dependencies:
  • Operator: v.1.6.8
  • WebConsole: v.1.7.345
  • Radix API: v.1.0.1