probe: cyberchef only, to separate resource contention from the rest

The two-leg run on Gitea left the cyberchef pod Pending with no node and no scheduling event, while its k3s node logged a Starting event 17s after the deployment was created - the node restarted under it. Two k3s clusters share one runner container there (6 CPU / 12Gi per #227), where on GitHub two legs are two VMs. A single leg, repeated, tells contention apart from a real fault.
probe: both charts (GitHub host path, with the race fixed)
2026-09-17 00:39:05 +02:00 · 2026-09-17 00:39:01 +02:00 · 2026-09-17 00:38:41 +02:00
2 changed files with 21 additions and 2 deletions
@@ -451,7 +451,26 @@ jobs:
          # Proves reachability here rather than letting it surface two steps
          # later as a validation error on the fixtures, which is where it
          # showed up before and named nothing useful.
-          kubectl cluster-info
+          #
+          # Polled, not asked once. k3d's --wait returns when the node
+          # container reports ready, but the API server can still answer
+          # discovery with 503 for a moment afterwards. Measured the hard way:
+          # a bare `kubectl cluster-info` right here failed with
+          # "ServiceUnavailable: the server is currently unable to handle the
+          # request" on one of two legs of the same GitHub run while the other
+          # passed - a check that is itself racy is worse than no check, since
+          # it produces exactly the sporadic red this job must not have. The
+          # loop asks for the node list, which is the thing that has to work
+          # and exercises discovery on the way.
+          for ATTEMPT in $(seq 1 60); do
+            kubectl get nodes >/dev/null 2>&1 && break
+            if [ "$ATTEMPT" -eq 60 ]; then
+              echo "::error::the k3d cluster '$CLUSTER' was created but never became reachable"
+              kubectl get nodes || true
+              exit 1
+            fi
+            sleep 2
+          done
          kubectl get nodes
      # Every chart reaching this step is one the exclusion filter let through,
      # so the script's SKIP branch is never taken here - it exists for local
@@ -8,7 +8,7 @@ description: A Helm chart to deploy a Wireguard-tunneled media automation stack

 type: application

-version: 3.0.6+up1.0.0
+version: 3.0.5+up1.0.0
 # The chart's own version marker, freely chosen and tied to no upstream. The
 # stack bundles nine independently versioned projects, so there is no single
 # "app version" to track here.
Author	SHA1	Message	Date
jklein	ad573406a5	probe: cyberchef only, to separate resource contention from the rest Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s Details Validate Helm Charts / Resource quantities (pull_request) Successful in 7s Details Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 4s Details Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 10s Details Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Failing after 5m30s Details The two-leg run on Gitea left the cyberchef pod Pending with no node and no scheduling event, while its k3s node logged a Starting event 17s after the deployment was created - the node restarted under it. Two k3s clusters share one runner container there (6 CPU / 12Gi per #227), where on GitHub two legs are two VMs. A single leg, repeated, tells contention apart from a real fault.	2026-09-17 00:39:05 +02:00
jklein	eaaad24b98	probe: both charts (GitHub host path, with the race fixed)	2026-09-17 00:39:01 +02:00
jklein	4766126618	install-test: poll for the cluster instead of asking once The reachability check added with the containerisation fix was itself racy and went red on one of two legs of the same GitHub run: k3d's --wait returns when the node container reports ready, but the API server can still answer discovery with 503 for a moment after that, and kubectl cluster-info asked exactly once. A check that produces sporadic red is worse than no check - that is the one property #227 rules out explicitly. It now polls kubectl get nodes, which is the thing that has to work and exercises discovery on the way.	2026-09-17 00:38:41 +02:00