From 0f631e747fee0c795040e987cce6875d9c999bf4 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Wed, 30 Sep 2026 15:32:57 +0000 Subject: [PATCH] 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 | 2 +- convertx.md | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/CI-CD.md b/CI-CD.md index 860f826..0441181 100644 --- a/CI-CD.md +++ b/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 diff --git a/convertx.md b/convertx.md index 172b783..a6207c0 100644 --- a/convertx.md +++ b/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-` 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).