Print the HTTPRoute URL in NOTES.txt without an Ingress

What does this MR do?

This is the follow-up to the review of !83 (merged). With gatewayRoute.enabled: true and the Ingress disabled, NOTES.txt printed the commands for the active Service (by default a kubectl port-forward to it on 127.0.0.1:8080) and never the URL the HTTPRoute serves. It now prints that URL and a note on the Gateway listener it depends on:

1. Get the application URL by running these commands:
  https://openbao.example.com
     NOTE: The HTTPRoute ob-openbao attaches to the listener "openbao-web" of the Gateway "gateway" in namespace "secrets".
           The URL assumes that listener accepts HTTPS on the default port. To list the protocol and port of each listener, run:
           kubectl get --namespace secrets gateways.gateway.networking.k8s.io/gateway -o jsonpath='{range .spec.listeners[*]}{.name} {.protocol} {.port}{"\n"}{end}'

• The URL is gitlab.openbao.url, the one the Ingress branch already prints. Its hostname is the one the HTTPRoute matches (gitlab.openbao.hostname), and it is also the chart's default JWT audience (config.initialize.boundAudiences), so NOTES.txt and the audience OpenBao accepts name the same URL. Its scheme follows ingress.tls.enabled, as it does for the audience.
• The note is there because the scheme and the port really belong to the listener, on a Gateway the chart references but does not create. The Gateway's name, namespace and listener come from the parentRef that templates/httproute.yaml renders (gitlab.gatewayApi.gatewayRef), so the note and the route cannot disagree, also where the GitLab chart overrides that helper. Without gatewayRoute.sectionName the route attaches to the Gateway as a whole, and the note says so.
• The command spells the resource as gateways.gateway.networking.k8s.io, because Istio installs a Gateway kind of its own (networking.istio.io). On k3s, with a stand-in for that CRD beside the Gateway API one, the short name gateway still resolved to the Gateway API one, but the full name does not depend on how kubectl resolves it.

With the Ingress and the route both enabled, NOTES.txt prints the Ingress URL alone, as before (the URL is the same). Every other branch is unchanged.

The issue offered two ways: print the URL and say what it assumes, or print commands that read the listener's protocol and port when they run, the way the LoadBalancer branch reads the Service's address. I went with the first. The hostname is known when the chart renders, and the Gateway the GitLab chart creates defines openbao-web as HTTPS on port 443 by default. It is also what helm create generates for an HTTPRoute in Helm 3.19: the hostname URL and a note pointing at the Gateway's listener configuration. Reading the protocol and the port at run time would take a few more shell lines, and the URL would come out broken whenever the Gateway cannot be read (another namespace without permission, a mistyped name). If you prefer that version, I can switch.

I did not bump version in Chart.yaml, as !83 (merged) did not: its change went out in 0.20.1 with the bump that !82 (merged) carried. Tell me if you want a bump here.

Author's Checklist

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Ensure a release milestone is set. (I cannot set a milestone on this project.)
• MR title and description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• MR has a green pipeline on GitLab.com. (The three test-e2e jobs wait for a manual start. helm-lint, helm-unittest and check-values-schema pass locally, see the test plan.)
• When ready for review, MR is labeled workflowready for review per the MR workflow.

Expected

• Test plan indicating conditions for success has been posted and passes.
• Documentation is created or updated. (NOTES.txt is the only text this changes.)
• Tests are added.

Test plan and results

Chart checks, in registry.gitlab.com/gitlab-com/gl-infra/common-ci-tasks-images/helm:3.19.0 (the image the CI jobs use: Helm 3.19.0, helm-unittest 1.0.3, helm-values-schema-json 2.6.0, installed from its repository head as check-values-schema does):

• helm unittest ./: 94 tests on main, 100 on this branch, all passing.
• helm lint ./ --strict: 1 chart linted, 0 failed.
• helm schema && git diff --exit-code values.schema.json: no difference.

The new tests/notes_test.yaml against the templates of main: 5 of the 6 new tests fail. The sixth, the Ingress and the route both enabled, passes on main too, since that output does not change.

Each of these changes to the new template fails at least one test: the route branch put before the Ingress branch, the listener named even when sectionName is empty, the namespace without the release namespace as default, the scheme in the note fixed to HTTPS, and the Gateway read from values.yaml instead of the parentRef helper.

On k3s v1.33.0+k3s1 (the version the test-e2e job runs) with the Gateway API v1.3.0 standard CRDs, a Gateway gateway in secrets with the listeners http-default (HTTP, 80) and openbao-web (HTTPS, 443), and no controller:

$ helm install ob ./ -n secrets --set ingress.enabled=false --set gatewayRoute.enabled=true
...
NOTES:
1. Get the application URL by running these commands:
  https://openbao.example.com
     NOTE: The HTTPRoute ob-openbao attaches to the listener "openbao-web" of the Gateway "gateway" in namespace "secrets".
           The URL assumes that listener accepts HTTPS on the default port. To list the protocol and port of each listener, run:
           kubectl get --namespace secrets gateways.gateway.networking.k8s.io/gateway -o jsonpath='{range .spec.listeners[*]}{.name} {.protocol} {.port}{"\n"}{end}'

$ kubectl -n secrets get httproutes.gateway.networking.k8s.io ob-openbao -o jsonpath='hostnames={.spec.hostnames} parentRefs={.spec.parentRefs}'
hostnames=["openbao.example.com"] parentRefs=[{"group":"gateway.networking.k8s.io","kind":"Gateway","name":"gateway","sectionName":"openbao-web"}]

$ kubectl get --namespace secrets gateways.gateway.networking.k8s.io/gateway -o jsonpath='{range .spec.listeners[*]}{.name} {.protocol} {.port}{"\n"}{end}'
http-default HTTP 80
openbao-web HTTPS 443

The last command was copied from the NOTES and run in the k3s container's sh.

helm template with the route enabled and, in turn, Ingress TLS off and another hostname, another Gateway name, namespace and listener, no sectionName, and a LoadBalancer Service: each renders, and the NOTES show the URL and the note above with those values. In twelve other value sets, with the Ingress (by default, with its TLS off, with the route also enabled, with the route explicitly off) and without it (each Service type, with TLS, with a custom API port), the NOTES are byte for byte those of main.

Vendored in the GitLab chart (gitlab-org/charts/gitlab at 9eb212b1, its other dependencies left out of Chart.yaml) with global.gatewayApi.enabled=true and global.ingress.enabled=false, helm template renders. That matters because Helm renders a subchart's NOTES.txt even when it does not print it, so an error there would fail the whole release. The subchart's NOTES, included from a scratch template, name the Gateway of the route's parentRef as the GitLab chart's helper renders it: gitlab-gw in the release namespace by default, and the name and namespace of global.gatewayApi.gatewayRef when those are set. With global.ingress.enabled=true they print the Ingress URL alone, as on main.

Related issues

Closes #46 (closed)