Feature: Allow HelmRelease to specify sourceRef from a ConfigMap

[mvaal]

Similar to how you can specify valuesFrom for chart values from a configmap, we should be able to specify sourceRefFrom and provide the values from a configmap. https://fluxcd.io/docs/guides/helmreleases/#refer-to-values-in-configmap-and-secret-resources

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 5m
  chart:
    spec:
      chart: <name|path>
      version: '4.0.x'
      sourceRefFrom: # example
        kind: ConfigMap
        name: source-ref
        valuesKey: source-ref-config.yaml

The reasoning behind the feature is that we need to pull from different helm repositories from different clusters. Rather than having a HelmRelease per cluster, we would like to create a single configmap per cluster that the same HelmRelease can pull from.

[makkes]

@mvaal maybe a solution that would leverage existing Flux functionality (so you can use it today) is to use substitution variables. Your HelmRelease manifests would look like this then:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: cert-manager
  namespace: default
spec:
  chart:
    spec:
      chart: cert-manager
      sourceRef:
        kind: ${helmSourceKind}
        name: ${helmSourceName}
        namespace: ${helmSourceNamespace}
      version: v1.5.4

Then the Kustomization would have to look like this:

apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: my-kustomization
  namespace: default
spec:
  path: ./services/cert-manager
  postBuild:
    substituteFrom:
    - kind: ConfigMap
      name: substitution-vars

And finally the substitution-vars ConfigMap would contain the actual Helm repository name:

apiVersion: v1
kind: ConfigMap
metadata:
  name: substitution-vars
  namespace: default
data:
  helmSourceNamespace: default
  helmSourceName: jetstack
  helmSourceKind: HelmRepository

[mvaal]

I appreciate the suggestion @makkes . The way we are doing deployments we are not able to use Kustomizations unfortunately so it doesn't solve my problem. Your suggestion is good and I did utilize this elsewhere though, so thanks for the tip.