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:

```yaml
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:

```yaml
global:
  job:
    nameSuffixOverride: '{{ dateInZone "2006-01-02-15-04-05" (now) "UTC" }}'
```

Alternatively, you can use it with `helm` in the command line:

```shell
helm <command> <options> --set global.job.nameSuffixOverride=$(date +%Y-%m-%d-%H-%M-%S)
```

Changelog: changed