Feature: variable substitution on Helm chart source from Git Repo + surface part of sources status as default substitution variables

[gberche-orange]

I sometimes need to author a small helm release in my git repo just to leverage the helm templating syntax not available in the kustomize controller (see the htpasswd-secret-generator-helm-chart below as an example). This avoids the extra overhead of publishing the helm release into a repository. Also this favors collaboration amon team members in a mono-repo setup.

$ tree
.
└── htpasswd-secret-generator-helm-chart
    ├── Chart.yaml
    ├── templates
    │   ├── basic-auth-secret.yaml
    │   └── _helpers.tpl.yaml
    └── values.yaml

$ cat Chart.yaml
apiVersion: v2
name: htpasswd-secret-generator-helm-chart
description: basic helm chart to generate basic auth compatible Secret
[...]
version: 55.0.2
appVersion: "55.0.2"

$ cat templates/ basic-auth-secret.yaml

apiVersion: v1
kind: Secret
type: Opaque

metadata:
  name: {{ .Values.target_secret }}
  annotations: {}
  labels:
    {{- include "htpasswd-secret-generator-helm-chart.labels" . | nindent 4 }}
data:
  auth: {{ (htpasswd .Values.user .Values.password) | b64enc | quote }}

It is referenced as a HelmRelease with a git repo source

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: dashboard-credentials-generator
spec:
  chart:
    spec:
      chart: shared-operators/k8s-kustomize-bases/00-utils-helm-charts/htpasswd-secret-generator-helm-chart
      sourceRef:
        name: paas-k8s-gitops-repo
        namespace: fluxcd
        kind: GitRepository
  interval: 5m
  values:
    user: kafka-admin-user
    password: ${service_admin_user_password}
    target_secret: dashboard-credentials #this secret will be generated, later used by ingress for basic auth security

It would be quite productive for an author to just commit and push changes to the helm release source code and see the helm release controller pickup the changes and trigger an helm update.

However, the helm-controler does not currently trigger an helm update unless the version in the Chart.yaml gets incremented.

It would be nice to be able to have pre-install variable substitution (similar to kustomize controller post-build variable substitution) within the helm controller that would be rendered prior to running the helm.

The chart.yaml would look like the following in the git repo:

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 55.0.2+${source.status.shortHash}

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "55.0.2"

Additionnally, part of sources status (such as GitRepository Status revision and lastUpdateTime) would be surfaced as default substitution variables.

For git commit fc5daaa9c008c5934920b3fa39b08f12e294030e, the version should be version: 55.0.2+fc5daaa therefore triggering a new helm chart uprade

The version with the substituted variable need to comply to semver, such as

https://semver.org/#spec-item-10

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

This would ease authoring of inlined HelmRelease within a git repo, it will not require anymore version bumps to trigger, while preserving reproductibility (w.r.t. possibility of specifying a "latest" version)