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 9s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Failing after 22s
Both charts in the matrix collide: Gitea runs the legs CONCURRENTLY in one job on one Docker daemon, and both create a cluster named install-test. One leg logs 'Re-using existing network', the other 'container name /k3d-install-test-server-0 is already in use', and the first rollback deletes the shared network under the second. The workflow is still byte-identical to PR #253 - only cyberchef is bumped now, which is the single-leg case most PRs actually produce, and the only way to see whether k3s itself comes up.