2 Commits

Include renames

Author	SHA1	Message	Date
jklein	be3e2cdd47	test(ci): exercise minecraft-server's NodePort branch, which nothing rendered ... Found by reviewing my own diff rather than by a failure, which is the only reason it is worth a commit of its own. minecraft-server's game-port rule has two branches read from the same value the Service reads: OPEN when server.service.type is NodePort, RESTRICTED to the namespace otherwise. All four releases in this cluster use ClusterIP and so does the install-test fixture - so the OPEN branch was rendered nowhere at all. Not by the chart defaults, not by the fixture, not by lint. It is also the branch where naming server.service.outwardPort instead of server.port would be the classic NodePort mistake, and assertion 2 can only see a rule it has been given. The overlay switches the Service to NodePort and RCON on, so both unreachable branches are now rendered on every pull request. RCON is in there for a reason too: its rule is gated on server.rcon.enabled exactly as the containerPort is, that pairing was wrong once while this chart was being written, and switching the feature on keeps the PAIR under test rather than just the gate. The overlay guard had to be made conditional for this to be possible, and the refinement is sound rather than a workaround. It demanded that any chart with an overlay render a source-restricted PROBE rule - but minecraft-server has no probe rule at all, because all three of its probes are exec probes, and it therefore offers no probeSources. The guard now applies only to charts that offer that value, so it still catches an overlay that stopped reaching the restricted probe branch (template-chart, the case it was written for) without rejecting an overlay that exists for a different unreachable branch. All twelve failure paths re-run against the change; the suite is 30 charts, 208 assertions, 0 failed. Part of #5	2026-10-14 15:29:16 +00:00
jklein	36bcfd3b11	feat(ci): assert every rendered NetworkPolicy against its own render ... The part that carries the rollout of Gitea #5. 29 charts get a policy that is on by default, and every way one of them can be wrong is SILENT: the API server accepts a policy that filters nothing just as readily as one that filters everything, and neither is a render error, so neither the build nor a rollout sees it. ci/run-networkpolicy-test.sh holds every rendered NetworkPolicy against the pod specs, probes and Services of the SAME render: 1. the podSelector really matches a pod of that render - otherwise the object sits in the namespace, is listed by kubectl, reads as a boundary and filters nothing, usually because a label was renamed in another file; 2. every INGRESS port is a containerPort of the selected pods, which catches the NodePort mistake mechanically. Egress ports are deliberately excluded: an egress port belongs to the DESTINATION, and comparing it would fail every chart that reaches a database; 3. no ingress rule allows every source by accident. "from: []" always fails - it allows everything while reading as a restriction. A MISSING "from" is the documented open form and is accepted only where the render justifies it: every port of the rule is addressed by a network probe, or published by a NodePort Service. That is stricter than the plan's wording, which banned both forms, and it had to be, because the precedents use the second one on purpose; 4. the probe path. For every port a NETWORK probe addresses, the policy either leaves it unrestricted or the chart offers networkPolicy.probeSources AND says in NOTES.txt that a list missing the node's IP leaves the pod permanently un-Ready. exec probes are excluded by design - they run inside the container and put no packet on the network, which is exactly why valkey and minecraft-server can restrict their port by source with no probeSources at all. Two guards beyond the four: a chart that renders NO policy fails, because that is how this issue decayed in the first place - garage and keycloak were both created after #5 and both arrived without one. And a "#" comment inside a rendered policy fails, because it is part of the object and is shipped to the cluster. Helm is the parser through ci/yaml2json, as in the other render tests: the runners have neither pyyaml nor yq, and a hand-written parser could read nothing, find nothing and leave this green over a chart it never looked at. Every failure path was run, not just the green ones, and one of them earned its keep immediately: the probeSources check was a substring test, so a chart whose key had been deleted while the comment above it still discussed the value passed. It now looks for the key. Part of #5	2026-10-14 13:56:06 +00:00