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(...)