jklein
7a2eb29e9e
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 14s
Validate Helm Charts / Selector match (pull_request) Successful in 14s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 14s
Validate Helm Charts / Build keycloak (pull_request) Successful in 8s
Validate Helm Charts / Trivy config keycloak (pull_request) Successful in 24s
Install-test / Install-test keycloak (pull_request) Successful in 3m29s
Validate Helm Charts / Install-test (pull_request) Successful in 3m29s
keycloak.realmHosts gives a realm a hostname of its own: this release's Service published under a further name, with that name's bare / sent to /realms/<realm>/account/. It renders in BOTH modes - one Ingress per entry carrying nginx.ingress.kubernetes.io/app-root, or one HTTPRoute per entry whose Exact match on / carries a RequestRedirect filter - because a routing value in this repository is mode-independent by design - ingress.domain is read in Gateway mode too - so a feature rendering in one mode only would silently disappear when an installation switched. Default []: nothing renders, and the render is byte-identical to 1.2.0 for the fixture's values in both modes. Minor, additive, no value becomes required. ONE OBJECT PER ENTRY, not one with several hostnames. spec.hostnames applies to the whole object and a rule's matches are path-based, so inside a shared route every entry would match Exact: / and the realm could not be told apart. Names therefore carry the LIST INDEX, as homeassistant's per-host routes do and for the same reason - a realm name is not a dependable object-name fragment. The consequence is written down rather than left to be discovered: reordering the list renames and recreates the objects. THE WORK IS IN THE INGRESS HALF, NOT THE ROUTE. Two convention rules do not survive these objects, and both deviations are required rather than tolerated: tlsSecretName is a per-entry value with NO default, because these hostnames already have certificates and several entries typically share one, so a derived name would ask cert-manager for a second certificate for a name a wildcard already covers; and the cert-manager annotation is OPTIONAL per entry, because cert-manager keys a Certificate by the secret it writes and only one object per secret may request it - the same deliberate omission the qBittorrent object in freesailarr makes. Annotations are per entry too: of the four hostnames this was written for, three carry the proxy-buffer pair and one does not, which a chart-global block could not express. statusCode: 302 is written out at the field's own default. 301 and 302 are both Support: Core, so the portability trap of #119 - an implementation declining an Extended code sets Accepted: False on the WHOLE route - does not apply here; ingress-nginx emits 302 for app-root, and a value that is only accidentally right documents nothing. Five render aborts, each against a failure that reports nothing: an entry without a host (ingress-nginx reads an empty host as a catch-all for the whole controller), without a realm (/realms//account/, a 404 behind a healthy hostname and certificate), without a tlsSecretName in Ingress mode (the controller's default certificate, a browser-only failure), a repeated host or one the release already publishes (webhook rejection in Ingress mode, two merged routes decided by object age in Gateway mode), and a filled list with both modes off (no object at all, and nothing in the release that reveals the list was ignored). The entry-shape checks sit in a shared helper so they exist in both modes, and the Ingress template skips them while httpRoute.enabled is also true so that the specific message cannot hide the mutual-exclusion one. CI: the two entries live in ci/keycloak/test-values.yaml, which ci/httproute/keycloak.yaml is applied on top of, so one definition covers both modes - two Ingress objects in the install-test, two HTTPRoutes in the render test. They cover both Ingress forms, with and without a clusterIssuer, and the render test holds their inertness in Gateway mode. The httproute match test goes from 56 assertions over 21 charts to 60, keycloak's share from 4 to 8 plus two "not checked" lines for the backend-less redirect rules. The #118 prefix/redirect pairing correctly does not fire: it is scoped to rules that strip a prefix, and a realm route strips nothing. NOT IN THIS CHANGE: the migration. Nothing in jk-cluster-config is touched. With the default [] no running system changes, so the order a takeover has to run in is documented instead - remove the objects in the owning repository first, then install with the list filled, because the reverse or both at once is rejected by ingress-nginx's admission webhook and leaves a Fleet bundle in ErrApplied until forceSyncGeneration is raised. Whether anything there depends on those objects BY NAME is unchecked and named as unchecked. Fixes #122
51 lines
2.5 KiB
YAML
51 lines
2.5 KiB
YAML
apiVersion: v2
|
|
name: keycloak
|
|
description: A Helm chart to deploy Keycloak, an OpenID Connect and SAML identity provider, as a two-node cluster on Kubernetes
|
|
icon: https://www.keycloak.org/resources/images/icon.svg
|
|
|
|
type: application
|
|
|
|
# appVersion is the exact image tag of quay.io/keycloak/keycloak. No "v"
|
|
# prefix here - upstream tags are plain three-part versions (26.8.0).
|
|
#
|
|
# THE TAG LANDSCAPE, AND WHY THIS CHART NEEDS NO VERSION CONSTRAINT. Measured
|
|
# on 2026-10-04 against quay.io's tag API, this registry carries four shapes
|
|
# side by side:
|
|
#
|
|
# 1. release tags 26.8.0, 26.7.5, ... <- what we track
|
|
# 2. REBUILD tags 26.8.0-0, 26.7.3-1, 26.7.2-2 - the same app
|
|
# version rebuilt (base image or CVE fix) without an app-version bump.
|
|
# 26.8.0-0 resolves to the SAME manifest digest as 26.8.0.
|
|
# 3. floating minor tags 26.8, 26.7, 26.6, ... - they move
|
|
# 4. floating names latest, nightly - they move daily
|
|
#
|
|
# This is the same GENUS of trap as garage's commit-SHA tags and stalwart's
|
|
# moving names, and it is the one case in this repo where the answer came out
|
|
# the other way: plain `docker` versioning already excludes all three unwanted
|
|
# shapes, so the renovate.json5 block carries NO versioningTemplate. Docker
|
|
# versioning splits a tag at the first dash and only ever offers candidates
|
|
# with the SAME suffix - our value has none, so the -N rebuilds are invisible
|
|
# to it - and 26.8 fails on the missing third part while latest/nightly parse
|
|
# as no version at all.
|
|
#
|
|
# THAT IS MEASURED, NOT ASSUMED, and the measurement is written down because
|
|
# the next round will otherwise add a constraint "to be safe" (renovate 44.132.5,
|
|
# --platform=local --dry-run=lookup against the real registry):
|
|
# appVersion 26.8.0 -> updates [], warnings []
|
|
# appVersion 26.7.0 -> exactly one: 26.8.0 (minor)
|
|
# appVersion 26.7.4 -> exactly two: 26.7.5 (patch), 26.8.0 (minor)
|
|
# No run offered a rebuild tag, a floating minor, latest or nightly.
|
|
#
|
|
# AND THE OTHER HALF, WHICH THE VERSION NUMBER CANNOT CARRY: Keycloak supports
|
|
# a rolling update only WITHIN a minor line. A minor jump needs the cluster
|
|
# shut down. The global `automerge: true` in renovate.json5 applies here
|
|
# anyway - a deliberate acceptance of that risk, not an oversight - so the
|
|
# procedure lives in NOTES.txt and on the wiki page instead of in a
|
|
# packageRules entry. Read the "MINOR UPGRADES" section of NOTES.txt before
|
|
# merging an app-version PR that changes the minor.
|
|
version: 1.3.0+up26.8.0
|
|
appVersion: "26.8.0"
|
|
|
|
maintainers:
|
|
- name: jklein
|