A gitops action to automatically push new helm chart versions for flux2

[cep21]

I recently wrote helm-autoupdate. We use it to automatically push new helm chart versions with flux.

The existing way:

     sourceRef:
        kind: HelmRepository
        name: aws
      version: "*"

Does not feel very gitops to us since we cannot track in git when a deployment happens. We also cannot use git revert or setup a PR for the change before it goes into production. Instead we use helm-autoupdate and our HelmRelease object looks like this:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: aws-vpc-cni
spec:
  chart:
    spec:
      chart: aws-vpc-cni
      sourceRef:
        kind: HelmRepository
        name: aws
      version: 0.0.1 # helm:autoupdate:aws-vpc-cni
  interval: 1m0s
  timeout: 10m
  values:
    replicaCount: 1

With this system, we can cron helm-autoupdate (as well as manually trigger it when we build internal charts) and have PRs (with all our PR status checks) for new helm chart releases.

[cep21]

Our current setup is to push "*" for all charts to our operations staging cluster (which only has our core services), setup alerts, and work on keeping charts up to date if a major version change breaks existing values.

[stefanprodan]

If you use a container registry to store the Helm charts, then Flux image automation can be used to bump the chart versions in Git.
See https://github.com/fluxcd/flux2/tree/main/rfcs/0002-helm-oci#story-2

[cep21]

Thanks for the link! I'm unsure we're at the point of moving everything to OCI (especially with our external dependencies mostly hosted on github self hosted HTTP pages). I'll keep this alternative approach in mind.

[tuxillo]

Thanks for this, I'm testing it right now.

[cep21]

Two years later, so many public helm charts are still on HTTP hosted on github and we still need something like this to update them

[kingdonb]

Does not feel very gitops to us since we cannot track in git when a deployment happens.

This is something I wrestled with too, in the end I found it's more noise, but it should be up to users whether the locus of control for which release is deployed comes from the Cluster repo or the App repo.

This should be true whether automation is used or otherwise.

We also cannot use git revert or setup a PR for the change before it goes into production

With the new OCI support, you can make production based on a label as in:

flux push artifact oci://ghcr.io/kingdonb/manifests/cluster:production --path=./clusters/ \
  --source="$(git config --get remote.origin.url)" \
  --revision="$(git tag --points-at HEAD)/$(git rev-parse HEAD)"

I demonstrated this use case which makes a production approval step in GitHub Actions last week on the Cloud Native Live stream:

https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cloud-native-live-vscode-and-flux-testing-the-new-unreleased-oci-repository-feature/

This helm-autoupdate releaser that you built is really quite neat, it fills the gap of these pre-OCI solutions which aren't quite usable with Flux's ImageUpdateAutomation. FWIW, there's also RenovateBot which is open source, will upgrade HelmRepository in a PR when updates are available, will upgrade Flux via PR when available, will generally post the Changelog inclusive of any upgrades that have been skipped, and has a number of use cases within the Flux umbrella that make it really nice as well.

It's not quite as Fluxy or integrated with Flux concepts as what you built. That looks really useful too! Thanks much for sharing, starred and saved for later 👍