jlab-cluster/helm-charts
3
0 Fork 0
Code Issues 15 Pull Requests 3 Actions Packages Wiki Activity

probe: single chart, to isolate whether k3s boots at all
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Details
Validate Helm Charts / Resource quantities (pull_request) Successful in 8s
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 9s
Details
Validate Helm Charts / Install-test ${{ fromJSON(needs.detect-changed-charts.outputs.install-charts) }} (pull_request) Failing after 22s
Details

Browse Source 
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.
This commit is contained in:
jklein committed 2026-09-17 00:14:03 +02:00
1 parent 9a676c1700
commit 2775e5d850
1 file changed
+1 -1
Download Patch File Download Diff File Expand all files Collapse all files
freesailarr/Chart.yaml
+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.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.