From 6e196c26a569506e27d0f7638f3ad45736cd6580 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Tue, 6 Oct 2026 11:43:46 +0000 Subject: [PATCH] test(ci): restore the theme mount - the A/B shows the restart is pre-existing --- ci/keycloak/test-values.yaml | 93 ++++++++++++++++++------------------ 1 file changed, 46 insertions(+), 47 deletions(-) diff --git a/ci/keycloak/test-values.yaml b/ci/keycloak/test-values.yaml index aa66a25..4d5f552 100644 --- a/ci/keycloak/test-values.yaml +++ b/ci/keycloak/test-values.yaml @@ -30,32 +30,39 @@ # first over the database would fail the run. Measured in Gitea PR #87: # 71.8s from `helm install` to both Ready, 0 restarts - three runs, all # three 72s and 0 restarts. -# THE RUNS OF PR #92 WERE NOT THAT, AND THE NUMBERS ARE RECORDED RATHER -# THAN SMOOTHED. Identical pod spec in all four - the later commits on that -# branch change comments only: -# run 585: 101s, ONE restart on one of the two pods -# run 590: 82s, 0 restarts -# run 593: 191s, 0 restarts -# run 595: 101s, ONE restart on one of the two pods -# Three things that are worth more than the average: the restart is -# INTERMITTENT on an unchanged spec (2 of 4), it is always exactly ONE on -# ONE pod, about 35s before that pod reports Ready - and it does not track -# the runner's speed, which was the first explanation and does not hold: -# the FASTEST (82s) and the SLOWEST (191s) run restarted nothing, and the -# two that restarted were both 101s. -# WHAT THE RESTART IS HAS NOT BEEN ESTABLISHED, and that is the lasting -# finding of the series: the harness dumps container logs only when a run -# FAILS (diagnose() hangs off the EXIT trap behind "RC -ne 0") and all four -# passed - A GREEN RUN CANNOT EXPLAIN A RESTART IT REPORTS. Answering it +# THAT WAS LUCK, OR A FAST WEEK, AND NOT AN INVARIANT - which took an A/B +# inside Gitea PR #92 to establish, because the first five runs there made +# it look like the new theme mount had destabilized the start: +# WITH the theme mount (spec of #88) +# run 585: 101s, ONE restart on one pod +# run 590: 82s, 0 +# run 593: 191s, 0 +# run 595: 101s, ONE +# run 597: 111s, ONE -> 3 of 5 +# WITHOUT it (the same branch, the pair commented out; pod template +# hash 5844db56b6, i.e. BYTE-IDENTICAL to the spec PR #87 measured) +# run 598: 81s, 0 +# run 599: 171s, ONE -> 1 of 2 +# So the restart happens WITHOUT the mount as well, and #88 is not its +# cause. It is pre-existing, intermittent behaviour of THIS chart's first +# install: always exactly one restart on one pod, 35-80s before that pod +# reports Ready. It does not track the runner's speed either - the fastest +# (81s) and the slowest (191s) run of the whole series restarted nothing. +# WHAT THE RESTART IS HAS NOT BEEN ESTABLISHED, and that is the finding +# worth keeping: the harness dumps container logs only when a run FAILS +# (diagnose() hangs off the EXIT trap behind "RC -ne 0") and all seven runs +# PASSED - A GREEN RUN CANNOT EXPLAIN A RESTART IT REPORTS. Answering it # means making the final-state step print the restart reasons whenever a -# counter is above zero; that is a change to ci/run-install-test.sh and it -# was deliberately NOT made inside #88. -# The counting stops here on purpose - every further commit adds a run, and -# a comment that chases the tally is wrong at the next push. What is worth -# carrying is the shape, not the tally: "0 restarts" is an observation, not -# an invariant of this chart, and a first install that serializes two -# replicas on a schema migration lock is a plausible place for one - which -# is a hypothesis, stated as one, because nothing here measured it. +# counter is above zero; that is a change to ci/run-install-test.sh with a +# CI-CD wiki obligation of its own, and it was deliberately NOT made inside +# #88. A first install that serializes two replicas on the Liquibase +# migration lock is a plausible place for it - stated as the hypothesis it +# is, because nothing here measured it. +# THE METHOD IS THE PART TO REUSE: a counter that moved in the same round +# as a change is not evidence against the change until the control case has +# run on the SAME machine. Three clean runs two days earlier were not that +# control, and treating them as one would have cost this PR its conclusion +# in both directions. # 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. @@ -181,28 +188,20 @@ keycloak: # 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. - # TEMPORARILY DISABLED FOR AN A/B MEASUREMENT, RESTORED BEFORE THIS PR IS - # MERGED. Three of five runs with the mount restarted one pod once, while the - # three runs of PR #87 without it restarted none - too close to be dismissed - # and not establishable from a green log. So the control case is measured on - # the SAME runner: this commit is the chart's pre-#88 fixture, the next one - # puts the mount back with the numbers written down. - # Control runs so far: 598 -> 81s, 0 restarts (pod template hash 5844db56b6, - # i.e. byte-identical to the spec PR #87 measured). - # If this commit is what - # reaches main, the restore was lost and the install-test no longer walks the - # path #88 added. - # extraVolumes: - # - name: login-theme - # configMap: - # name: ci-keycloak-theme - # items: - # - key: theme.properties - # path: login/theme.properties - # extraVolumeMounts: - # - name: login-theme - # mountPath: /opt/keycloak/themes/ci-theme - # readOnly: true + 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