Replace usage of Helm release revision with a stable hash in Job names
What does this MR do?
Originally jobs in GitLab were suffixed with the Helm
.Release.Revision
which was not ideal because it would always cause an
update of the job when running helm upgrade --install
, even if nothing
has changed. And it also prevented the proper work with workflows that
are based on helm template
for example when using ArgoCD. The decision
to use the .Release.Revision
in the name was based on the
preconditions that the job might only be executed once and that
helm uninstall
wouldn't delete jobs, which are (now) wrong.
Now, job names by default are suffixed with a hash that is based on the
chart's app version and the chart's values, which also might contain the
global.gitlabVersion
. This approach ensures job names remain stable
across multiple helm template
and helm upgrade --install
executions
(if nothing changed), and it's even possible to modify values of
immutable fields of the job without errors during deployments (the jobs
are just replaced with new ones due to the new names).
It is possible to override the hash that gets generared by default with
a custom suffix by setting global.job.nameSuffixOverride
. The field
supports templating, so it is possible to reproduce the old behavior of
using the .Release.Revision
as a name suffix:
global:
job:
nameSuffixOverride: '{{ .Release.Revision }}'
If you intentionally always want to trigger a change, for example
because you are working with floating tags such as latest
for all
your versions, you can override the hash that gets generated by default
with a dynamic value such as a timestamp:
global:
job:
nameSuffixOverride: '{{ dateInZone "2006-01-02-15-04-05" (now) "UTC" }}'
Alternatively, you can use it with helm
in the command line:
helm <command> <options> --set global.job.nameSuffixOverride=$(date +%Y-%m-%d-%H-%M-%S)
Related issues
Closes #734 (closed)
Closes #3021 (closed)
Closes #3832 (closed)
Related to !2863 (closed)
Related to !3528 (closed)
Author checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion.
Required
-
Merge Request Title and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com (https://gitlab.com/gitlab-org/charts/gitlab/-/pipelines/1218352969) -
When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow
For merge requests from forks, consider the following options for Danger to work properly:
- Consider using our community forks instead of forking your own project. These community forks have the GitLab API token preconfigured.
- Alternatively, see our documentation on configuring Danger for personal forks.
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes (!3602 (comment 1778303818)) -
Documentation created/updated -
Tests added/updated -
Integration tests added to GitLab QA -
Equivalent MR/issue for omnibus-gitlab opened~~ I guess not needed? -
Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes) -> gitlab-org/cloud-native/gitlab-operator#1530 (closed) -
Validate potential values for new configuration settings. Formats such as integer10
, duration10s
, URIscheme://user:passwd@host:port
may require quotation or other special handling when rendered in a template and written to a configuration file.
Test plan
This is tested by manually tweaking version and appVersion in Chart.yaml on a local copy and using helm template --set ... test . | yq 'select(.kind == "Job") | .metadata.name'
to verify different scenarios.