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.