Skip to content

fix: ingress.configureCertmanager to have higher priority than global

What does this MR do?

The Helm template helper function gitlab.certmanager_annotations gave .Values.global.ingress.configureCertmanager a higher priority than a specific Helm chart's configuration.

This change makes the specific Helm chart's configuration take precedence over the global configuration.

Also note that my attempted workarounds to unset the global configuration fail (at least with helm 3.5.3).

For debugging of this, you can use the following command, where you should not see a certmanager annotation listed if the specific chart's configuration (webservice) should have any meaning.

helm template RELEASE_NAME ./ --show-only charts/gitlab/charts/webservice/templates/ingress.yaml --set certmanager-issuer.email=dummy --set gitlab.webservice.ingress.configureCertmanager=false

Failed workaround attempt:

global:
    ingress:
    # If this is set at all, it will take precedence over any other
    # chart specific configuration. Setting it to null won't suffice
    # though.
    configureCertmanager: null

webservice:
    ingress:
    configureCertmanager: true

registry:
    ingress:
    configureCertmanager: true

Motivation

I wanted cert-manager to provide all TLS certificates for use with all Ingress resources, except for gitlab-pages. This is because I understood I needed a wildcard certificate and knew that I could only acquire that manually. So, I simply wanted to disable the annotation to trigger cert-manager to try acquire a TLS certificate for the gitlab-pages Ingress resource specifically, but not change anything else.

Related info

This was tested against current master (latest tag: v4.11.3).

Related issues

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

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes Hmmm, what does this mean?
  • Documentation created/updated
  • Tests added Manually tested, but no tests have been added.
  • Integration tests added to GitLab QA That would be a bit more work than I'm ready to do for this fix.
  • Equivalent MR/issue for omnibus-gitlab opened Not needed: This was a Helm chart specific change.
Edited by Erik Sundell

Merge request reports