Skip to content

Replace usages of `.Release.Revision` to support deployment workflows based on `helm template`

Summary

As the title states, I suggest to replace all usages of .Release.Revision to support workflows where the output of helm template is used instantly or later to perform a deployment.

Currently, .Release.Revision is used in the following templates:

charts/certmanager-issuer/templates/_helpers.tpl
27:{{- printf "%s-%d" $name .Release.Revision | trunc 63 | trimSuffix "-" -}}

charts/gitlab/charts/migrations/templates/_helpers.tpl
12:{{- printf "%s-%d" $name .Release.Revision | trunc 63 | trimSuffix "-" -}}

charts/minio/templates/_helpers.tpl
38:{{- printf "%s-create-buckets-%d" $name .Release.Revision -}}

charts/registry/templates/_helpers.tpl
173:{{- printf "%s-migrations-%d" $name .Release.Revision | trunc 63 | trimSuffix "-" -}}

templates/_helpers.tpl
577:{{- printf "%s-%d-%s" $name .Release.Revision $rand | trunc 63 | trimSuffix "-" -}}

Unfortunately, helm template does not support overriding .Release.Revision so that helm template always evaluates this template to the value 1 (also see https://github.com/helm/helm/issues/10690). And this causes problems during the deployment, e.g. of the GitLab "migrations" job, where this value is intended to be used to "update" the job (also see https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/charts/gitlab/charts/migrations/templates/_helpers.tpl).

A more reliable way to deal with these job updates would maybe be to work with a checksum or a date value. This would allow to support such workflows based on helm template. Many people believe that every Helm chart should allow to work with such a workflow. And replacing the old behavior with a new one should not affect users.

Btw. we are not using such a workflow based on helm template directly, but indirectly by using Helmfile and Helmfile's "ad-hoc dependency" feature. For more input, have a look at my issue there: https://github.com/helmfile/helmfile/issues/430

Steps to reproduce

not needed

Configuration used

not needed

Current behavior

Deployment fails because trying to update the same job.

Expected behavior

Allow updates of jobs without "knowing" the current revision.

Versions

  • Chart: 6.4.2
  • Platform:
    • Cloud: AKS
  • Kubernetes: (kubectl version)
    • Client: 1.21.4
    • Server: 1.22.6
  • Helm: (helm version)
    • Client: 3.9.0
    • Server:

Relevant logs

Error: UPGRADE FAILED: cannot patch "gitlab-migrations-1" with kind Job: Job.batch "gitlab-migrations-1" is invalid: spec.template: Invalid value: core.PodTemplateSpec(...)