Update controller release flow

[moklidia]

1. Created automated GH releases with generated changelog
2. Change the appVersion in the Chart.yaml automatically during release

[axisofentropy]

• the existing app's Makefile command to update the app version should update appVersion in Chart.yaml instead of version.
• it would be helpful (tho not critical) to have a separate command to iterate the Helm chart version.
• we can update the GHA workflow release-qa to do helm upgrade on the qa cluster instead of just updating the image. it can use the source within the qa branch without packaging a Helm chart version and without doing a GitHub release. We'll look at the helm CLI options we're using in Terraform now, and maybe try the dependency-update flag too.

[axisofentropy]

When running helm upgrade within a GHA workflow, here are some helpful CLI options:

• --install "if a release by this name doesn't already exist, run an install" idempotent!
• --atomic "if set, upgrade process rolls back changes made in case of failed upgrade." don't leave the cluster broken!
• --dependency-update hopefully pulls new dependency charts
• --cleanup-on-fail probably safe here
• --timeout 15m more time to troubleshoot if it hangs (default 5m)
• --verify good for any CI/CD workflow
• --render-subchart-notes sure why not

We might need to use --reuse-values but it's better if we don't. Test by running helm get values on the release before and after this workflow first runs.

you can read about these options and more here: https://helm.sh/docs/helm/helm_upgrade/

[zipofar]

About reuse-values and reset-values

[zipofar]

The flag --render-subchart-notes show us. I think this is not relevant for us

NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace uffizzi get services -o wide -w uffizzi-ingress-nginx-controller'

An example Ingress that makes use of the controller:
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 80
              path: /
    # This section is only required if TLS is to be enabled for the Ingress
    tls:
      - hosts:
        - www.example.com
        secretName: example-tls

If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:

  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
    tls.crt: <base64 encoded cert>
    tls.key: <base64 encoded key>
  type: kubernetes.io/tls

cert-manager v1.12.4 has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/

CHART NAME: flux
CHART VERSION: 0.3.11
APP VERSION: 0.36.1

** Please be patient while the chart is being deployed **

The following controllers have been deployed:
  - helm-controller
  - source-controller

Check the status of the pods by running this command:

  kubectl get pods --namespace "uffizzi" -l app.kubernetes.io/instance=uffizzi

Read the upstream flux documentation to start working with the controllers:

  https://fluxcd.io/flux/components/

[zipofar]

The flag --verify does not work with unpacked chart

Error: unpacked charts cannot be verified