feat(keycloak): extraVolumes/extraVolumeMounts for custom themes and providers (1.1.0+up26.8.0)

ci/keycloak/test-values.yaml

@@ -29,6 +29,9 @@
 #      that crashed, deadlocked on the schema migration lock or fought the
 #      first over the database would fail the run. Measured in Gitea PR #87:
 #      71.8s from `helm install` to both Ready, 0 restarts.
+#   5. A MOUNTED LOGIN THEME SURVIVES ALL OF THAT (Gitea #88) - the full
+#      argument sits at keycloak.extraVolumes further down, including what it
+#      still does not prove.
 #   Plus the mechanical half: the Secret key names match what the Deployment
 #   references, /health/started, /health/live and /health/ready all answer on
 #   the management port (so health-enabled really was baked in by the init
@@ -124,6 +127,48 @@ keycloak:
         memory: 512Mi
         ephemeral-storage: 256Mi
 
+  # THE EXTRA VOLUME PAIR, WALKED RATHER THAN RENDERED (Gitea #88). The theme
+  # ConfigMap comes from fixtures.yaml. Three things this puts inside the
+  # assertion that no render reaches:
+  #
+  #   1. A MOUNT ON A SUBPATH OF A DIRECTORY THAT EXISTS IN THE IMAGE IS
+  #      ACCEPTED ALONGSIDE readOnlyRootFilesystem: true.
+  #      /opt/keycloak/themes/ci-theme does not exist in the image, so the
+  #      runtime has to create the mount point inside a root filesystem that is
+  #      about to be read-only. If that did not work, every container of this
+  #      pod would fail to start.
+  #   2. `kc.sh build` STILL SUCCEEDS WITH THE EXTRA MOUNT PRESENT. The mounts
+  #      are rendered on the build init container too (that is what makes SPI
+  #      providers work at all), so this fixture is also the test that the extra
+  #      mount does not disturb the augmentation - a failure would leave the pod
+  #      in Init with the reason only in a log.
+  #   3. `start --optimized` COMES UP WITH A RUNTIME THEME IN PLACE. The plan of
+  #      #88 called that "a reasoned expectation, not verified"; a Ready pod with
+  #      this mounted is the verification, and it is the one that matters for the
+  #      unusual two-init-container construction of this chart.
+  #
+  # WHAT IT STILL DOES NOT PROVE, and it would be easy to overclaim here: that
+  # the LOGIN PAGE renders and that base/keycloak/keycloak.v2 are still listed.
+  # The health endpoints answer regardless of the themes directory, and nothing
+  # in this harness makes an HTTP request to / or runs a command in the pod. That
+  # the subpath hides nothing is a property of the mount path rather than a
+  # measurement - and the kcLogoIdP line needs a browser plus a realm setting,
+  # neither of which exists in CI.
+  extraVolumes:
+    - name: login-theme
+      configMap:
+        name: ci-keycloak-theme
+        items:
+          - key: theme.properties
+            path: login/theme.properties
+  extraVolumeMounts:
+    - name: login-theme
+      # THE SUBPATH, AND THE WHOLE POINT OF THE EXAMPLE: a volume on
+      # /opt/keycloak/themes would hide the image's own three themes and break
+      # the login page while the pod stayed Ready.
+      mountPath: /opt/keycloak/themes/ci-theme
+      readOnly: true
+
 ingress:
   # Left ON although no ingress controller answers in CI: the point is that
   # both objects are accepted and that the Service port they name BY NAME