{{/*
The Gateway-API alternative to sure.ingress.yaml (Gitea #114). Form and
reasoning: template-chart/templates/xxx.httproute.yaml and README, "Ingress and
Gateway API".

Only an HTTPRoute with parentRefs. No Gateway, no gatewayClassName, no
Certificate, and no implementation-specific policy object - that subset looks
identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is
the whole reason the cluster's implementation can be swapped without touching
this chart. Class and certificate therefore belong to the PLATFORM, on the
Gateway and its listeners.

ingress.clusterIssuer is meaningless here - this chart renders no Certificate
in this mode - and it is not demanded either: its only required() sits inside
sure.ingress.yaml, behind ingress.enabled.

THE ONE THING THIS CHART NEEDED BEYOND THE ROUTE: HOW RAILS IS TOLD ABOUT TLS

sure.commonEnv used to render RAILS_ASSUME_SSL and RAILS_FORCE_SSL from
ingress.enabled alone, which was exactly right while an Ingress was the only
way this release could be published. In Gateway mode ingress.enabled is false
BY CONSTRUCTION - the two modes are mutually exclusive - while TLS is still
terminated in front of the app, now at the Gateway's listener. Left as it was,
a Gateway-mode install would have come up with both flags false: Rails would
not trust the forwarded scheme, would hand out cookies without the Secure
attribute, would send no HSTS and would build absolute links as http://. The
pod goes Ready and the UI works, so nothing reports it - which is the class of
failure this repository treats as a defect rather than a default.

The flags therefore follow "is this release published through a TLS-terminating
proxy at all" (sure.publishedOverTls in _helpers.tpl), which is
ingress.enabled OR httpRoute.enabled. With httpRoute.enabled at its default of
false that expression IS ingress.enabled, so nothing changes for an existing
release - the behaviour only differs for a configuration that did not exist
before. A port-forwarded plain-HTTP session still gets both flags false and can
still log in.

ingress.domain IS STILL REQUIRED, AND NOT BECAUSE OF THIS FILE

Checked for this chart rather than copied: sure.commonEnv reads ingress.domain
with its own required(), three times over - APP_DOMAIN, WEBAUTHN_RP_ID and
WEBAUTHN_ALLOWED_ORIGINS. So domain is mandatory in every mode and the fallback
below is never the only reader. Mind WEBAUTHN_RP_ID in particular when
publishing under a new name: passkeys are bound to the relying party id, and
changing it invalidates every registered credential. That is a reason to be
careful with httpRoute.hostnames, which does NOT move the relying party id
with it.
*/}}
{{- /*
Null-safe like every other block this chart dereferences (#99): an override
written without children - "httpRoute:" with the keys below it deleted - is
YAML null, and `.Values.httpRoute.enabled` would abort the render with a nil
pointer. An empty block means "chart defaults apply", and all three defaults
are empty or false, so the whole block collapses to "no HTTPRoute".
*/ -}}
{{- $httpRoute := .Values.httpRoute | default dict -}}
{{- if and $httpRoute.enabled .Values.ingress.enabled -}}
{{- fail "ingress.enabled and httpRoute.enabled are both true - set exactly one of them. The Ingress and the HTTPRoute would publish the same Service under the same hostname over two different data paths, which is already a conflict at DNS level: one name, two addresses, and which one a client reaches is luck. A migration runs over a SECOND hostname (set httpRoute.hostnames explicitly while the Ingress keeps ingress.domain), never over parallel operation of both." -}}
{{- end -}}
{{- if $httpRoute.enabled -}}
{{- $parentRefs := $httpRoute.parentRefs | default list -}}
{{- if not $parentRefs -}}
{{- fail "httpRoute.enabled is true but httpRoute.parentRefs is empty - an HTTPRoute without a parent attaches to no Gateway. It is created, it is schema-valid, and it routes NOTHING, with no event and no condition that says so; the only symptom is a hostname that does not answer. Name the cluster's Gateway, e.g. httpRoute.parentRefs: [{name: public, namespace: gateway}]." -}}
{{- end -}}
{{- /*
One source of truth for the hostname: an empty httpRoute.hostnames means
[ingress.domain], so the two cannot drift apart. See the header for what
setting it explicitly does not move.
*/ -}}
{{- $hostnames := $httpRoute.hostnames | default list -}}
{{- if not $hostnames -}}
{{- $hostnames = list (required "A Domain/Host must be provided: set ingress.domain (used as the HTTPRoute's single hostname when httpRoute.hostnames is empty) or set httpRoute.hostnames explicitly" .Values.ingress.domain) -}}
{{- end -}}
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}-httproute
spec:
  parentRefs:
    {{- toYaml $parentRefs | nindent 4 }}
  hostnames:
    {{- toYaml $hostnames | nindent 4 }}
  rules:
    # The Ingress counterpart is `path: / , pathType: Prefix` on the one
    # backend Service - the web container serves everything; the worker has no
    # HTTP port and is never routed to. The port is the Service's port NUMBER
    # and not its name ("http"): backendRefs takes a PortNumber, so unlike the
    # Ingress this reference cannot be made by name and the 80 below has to
    # track sure.service.yaml by hand.
    # ci/run-httproute-match-test.sh is what holds that pair - it fails when a
    # backendRef names a Service, or a port, the same render does not create.
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: {{ .Release.Name }}-{{ .Chart.Name }}-service
          port: 80
{{- end }}