convertx, CI-CD: the measured install-test time

The chart's first green install-test leg took 2m35s including cluster
creation (Gitea PR #61), against an estimate of roughly five minutes for the
pull alone. Recorded in both places the estimate had been reasoned about.

The general point belongs on the CI-CD page rather than only on the chart
page: a large image moves the all-charts figure less than it looks, because
the legs run concurrently and that figure tracks the slowest leg plus
scheduling, never the sum of the pulls.

CI-CD.md

@@ -136,7 +136,7 @@ Not on a schedule: it would spend compute every day on a question that changes r
 | **One cluster per chart** | no reuse. Reuse saves time and changes what the test proves: leftovers of the previous install, a warm image cache, fixtures already applied. "Came up from nothing" is the statement. |
 | **Excluded charts** | dropped through the one parser, `ci/run-install-test.sh --list-excluded`, and listed in the summary **with their justification**, as in the PR pipeline. |
 | **The record** | per chart: outcome, date, runner label, `K3S_IMAGE`, `kubectl` version. Plus a final job with the verdict over the whole matrix. A green run nobody notes is unknown again next time. |
-| **Expected runtime** | **20 charts in 12m41s** (Gitea PR #48, one job, all legs concurrent on one Docker daemon). Written down so a later deviation is visible as one; compare it against the chart count the run prints in its own summary — 24 at the time of writing, and one more with every new chart. The timeout is 30 minutes per leg, in `install-test.yml`, hence identical for both callers. |
+| **Expected runtime** | **20 charts in 12m41s** (Gitea PR #48, one job, all legs concurrent on one Docker daemon). Written down so a later deviation is visible as one; compare it against the chart count the run prints in its own summary — 24 at the time of writing, and one more with every new chart. The timeout is 30 minutes per leg, in `install-test.yml`, hence identical for both callers. **A big image moves this less than it looks:** [convertx](convertx) is ~1.4 GiB compressed, by a wide margin the largest in the repo, and its first green leg measured **2m35s** including cluster creation (Gitea PR #61) — inside the existing envelope, not a new one. The legs run concurrently, so this figure tracks the *slowest* leg plus scheduling, never the sum of the pulls. |
 
 ## `ci/helm-dependencies.sh` — the step they all share
 

convertx.md

@@ -242,7 +242,9 @@ Rotating `jwt-secret` invalidates every existing session — which is the intend
 
 ## CI
 
-`ci/convertx/` holds `test-values.yaml` (an `op://` ref against the stub CRD, `convertx.ci.local`, a 1Gi volume), `fixtures.yaml` (the `jwt-secret` Secret the stub `OnePasswordItem` CRD cannot materialize — without it the pod hangs in `CreateContainerConfigError`) and `settings.env` with a raised `INSTALL_TIMEOUT`, because the rollout wait has to cover the ~1.4 GiB **pull** and not just the start. The install-test runs on every PR that touches the chart — see [CI/CD](CI-CD).
+`ci/convertx/` holds `test-values.yaml` (an `op://` ref against the stub CRD, `convertx.ci.local`, a 1Gi volume), `fixtures.yaml` (the `jwt-secret` Secret the stub `OnePasswordItem` CRD cannot materialize — without it the pod hangs in `CreateContainerConfigError`) and `settings.env` with `INSTALL_TIMEOUT=900`, because the rollout wait has to cover the ~1.4 GiB **pull** and not just the start. The install-test runs on every PR that touches the chart — see [CI/CD](CI-CD).
+
+The raised timeout turned out to be headroom rather than need: the first green leg measured **2m35s** including cluster creation (Gitea PR #61), against an estimate of roughly five minutes for the pull alone. It stays at 900s anyway — a rollout-wait timeout is a ceiling, not a cost, so the headroom is free on a good day and only spends time on a chart that is already failing.
 
 Renovate tracks `appVersion` with a regex anchored on the `v` prefix. The registry carries the versioned family next to three moving tags — `latest`, `main` and one `pr-<n>` per open pull request — and `v0.19.0` currently shares a digest with `latest`, which is exactly the trap the anchor exists for. See [Renovate](Renovate).