jklein
7ff54eecf7
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 8s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 4s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 10s
Install-test / Install-test ${{ fromJSON(inputs.charts) }} (pull_request) Successful in 2m32s
Validate Helm Charts / Install-test (pull_request) Successful in 2m32s
The first green install-test of the chart (Gitea PR #61) took 2m35s for the whole leg - cluster creation, fixtures, pull, install and rollout wait together. The estimate in settings.env had been around five minutes for the pull alone, extrapolated from the runner's 96 MB/17.5s reference; that reference does not transfer to ghcr.io on this runner. INSTALL_TIMEOUT stays at 900s. A rollout-wait timeout is a ceiling, not a cost - kubectl waits exactly as long as the rollout needs - so the headroom is free on a good day and only spends time on a chart that is already failing. The comment now states the measurement next to the reason. README gets the other half: a 1.4 GiB image was expected to move the all-charts expectation from Gitea #52 and does not, because the legs run concurrently and that figure tracks the slowest leg rather than the sum of the pulls.
24 lines
1.3 KiB
Bash
24 lines
1.3 KiB
Bash
# The image is ~1.4 GiB compressed - by a wide margin the largest in this
|
|
# repo, because LibreOffice, Calibre, ImageMagick, ffmpeg, Inkscape and a TeX
|
|
# Live installation are all inside it. One layer alone is 1354 MiB.
|
|
#
|
|
# The rollout wait therefore has to cover the PULL, not just the start: the
|
|
# runner reference point is 96 MB in 17.5s, which puts this image in the
|
|
# region of five minutes of pulling before the container is even created. On
|
|
# top of that comes the startup probe budget (30 x 10s = 300s), which is
|
|
# generous because ConvertX shells out to ~20 converter binaries at import
|
|
# just to log their versions.
|
|
#
|
|
# MEASURED, and the estimate was wrong in the safe direction: the first green
|
|
# install-test of this chart (Gitea PR #61) took 2m35s for the WHOLE job -
|
|
# cluster creation, fixtures, pull, install and rollout wait together. The
|
|
# 96 MB/17.5s reference does not transfer to ghcr.io on this runner.
|
|
#
|
|
# 900s stays anyway, and deliberately. A rollout-wait timeout is a ceiling,
|
|
# not a cost: kubectl waits exactly as long as the rollout needs, so a
|
|
# generous number is free on a good day and only spends time on a chart that
|
|
# is already failing. What it buys is the bad day - a cold registry, or a node
|
|
# that has to extract the 1354 MiB layer onto slow disk. The default of 300s
|
|
# would have no headroom at all for either.
|
|
INSTALL_TIMEOUT=900
|