1 Commits
Author SHA1 Message Date
jklein b0eca80b2a probe: both charts, both code paths
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 7s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 5s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 12s
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Failing after 5m32s
Workflow byte-identical to PR #253. cyberchef and freesailarr in the
matrix; this same branch also goes to GitHub as a throwaway PR, so the
containerised and the host branch of the cluster-creation step are both
exercised.
2026-09-17 00:29:20 +02:00
2 changed files with 2 additions and 21 deletions

No files matched your search

+1 -20
View File
@@ -451,26 +451,7 @@ 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.
#
# 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 cluster-info
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
+1 -1
View File
@@ -8,7 +8,7 @@ description: A Helm chart to deploy a Wireguard-tunneled media automation stack
type: application
version: 3.0.5+up1.0.0
version: 3.0.6+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.