jklein
d3ef3729f8
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 12s
Validate Helm Charts / Selector match (pull_request) Successful in 12s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 11s
Validate Helm Charts / Bump level (pull_request) Successful in 4s
Validate Helm Charts / YAML scalars (pull_request) Successful in 11s
Validate Helm Charts / NetworkPolicy (pull_request) Failing after 11s
Validate Helm Charts / Build cyberchef (pull_request) Successful in 7s
Validate Helm Charts / Trivy config cyberchef (pull_request) Successful in 18s
Validate Helm Charts / Build template-chart (pull_request) Successful in 7s
Validate Helm Charts / Trivy config template-chart (pull_request) Successful in 17s
Install-test / Install-test cyberchef (pull_request) Successful in 1m4s
Validate Helm Charts / Install-test (pull_request) Successful in 1m4s
The scope of Gitea #5 - 29 charts at once, default on - rests on the claim that the install-test enforces policies, so a policy that blocks the probe path goes red in CI rather than silently in production. k3d is created without --disable-network-policy, but a flag read off a workflow file is not evidence. This commit restricts cyberchef's probe port 8080 to 192.0.2.11/32, an RFC 5737 documentation address that cannot be the k3d node's IP. The kubelet probes from the node's own address, so they are dropped and the pod must never become Ready. Expected: the cyberchef install-test goes RED on rollout status. If it goes green, policies are not enforced in CI and the scope has to be renegotiated. Reverted in the next commit either way. Part of #5