5 Commits

Include renames

Author	SHA1	Message	Date
jklein	77b978d669	feat(outline)!: NetworkPolicy, on by default ... Major, as every chart in this rollout is. Inbound 3000 only; outbound DNS plus 5432, 6379 and 443. Those three egress ports are the STANDARD ones and not the configured ones, which is this chart's real limitation and is written into values.yaml, the template header and NOTES.txt rather than left to be discovered: Outline's database, Redis and OIDC provider all arrive as connection URLs inside 1Password items that the chart never parses, so it cannot know where they listen and cannot validate a guess. A dependency on another port is blocked, and because all three probes hit /_health - which checks Postgres and Redis - the symptom is a pod that never becomes Ready rather than an error anyone reads. networkPolicy.egress.extraPorts is the escape hatch. That same property is what makes this chart the right place for the enforcement experiment in the next commit. Also reverts the cyberchef fixture from the first experiment: with the probe port restricted to an address that is not the node's, the install-test went GREEN, so the claim that it catches a blocked probe path does not hold as written. The next commit establishes whether policies are enforced in CI at all. Part of #5	2026-10-14 14:07:06 +00:00
jklein	d3ef3729f8	test(ci): prove the install-test enforces NetworkPolicies [EXPERIMENT, reverted next] ... 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	2026-10-14 14:00:11 +00:00
jklein	50f683776e	feat(cyberchef): Gateway-API as an alternative to the Ingress (pilot) ... The Gateway-API pilot of Gitea #114: one chart, the convention, the CI that holds it. The remaining 20 charts follow in their own PRs. The form, additive and off by default: httpRoute: enabled: false # counterpart to ingress.enabled parentRefs: [] # the Gateway - a platform object hostnames: [] # empty = [ingress.domain] Only HTTPRoute with parentRefs is rendered: no Gateway, no gatewayClassName, no Certificate, and no implementation-specific policy object. That subset is identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is what lets the implementation be chosen later without touching the charts again. Class and certificate move to the platform. Four guards, all against silent failures: - mutually exclusive with ingress.enabled, with a render abort naming BOTH value paths. A migration runs over a second hostname, not in parallel. - parentRefs mandatory in Gateway mode, render abort on the empty list: a route without a parent is created, is schema-valid, and routes nothing. - hostnames empty means [ingress.domain], so the hostname has one source. - the mode is a VALUE, not auto-detection: .Capabilities.APIVersions is unreliable at template time and a missing CRD fails at install time. ingress.clusterIssuer was already only read inside the Ingress template, so the "conditionally required" half of #114 needed no change in this chart - checked rather than assumed, and it has to be re-checked per chart in the sweep. CI, both halves, because neither covers the other: - the install-test installs cyberchef in GATEWAY mode against the REAL Gateway-API CRDs (standard channel v1.6.3, pinned and Renovate-tracked, applied --server-side). A schema-less stub would accept a malformed route and prove only that something was created. The Ingress path of this one chart is no longer installed; it is a built-in type that never routed in k3d anyway, and helm lint renders this chart's defaults - Ingress mode - on every PR. - ci/run-httproute-match-test.sh, over every chart on every PR: every backendRefs entry must name a Service, on a port, that the SAME render creates, and parentRefs must not be empty. The CRDs accept both of those mistakes, so the schema cannot catch them, and the only report would be a route status no controller writes in CI. What stays unprovable, and is written down instead of implied: that traffic flows. No Gateway controller runs in k3d. Minor: additive with unchanged defaults, proven by an empty helm template diff against origin/main for the default values. Part of #114	2026-10-12 15:16:26 +00:00
jklein	22fdb58396	Strict clusterIssuer also for cyberchef and urlaubsverwaltung ... Per the maintainer decision (option a: ingress.clusterIssuer strictly required in ALL charts) the two remaining defaults are removed as well: - cyberchef: drop the letsencrypt default; bump raised from minor to major (6.0.0+up11.4.0) as this is a breaking values change. - urlaubsverwaltung: drop the letsencrypt-issuer default; major bump to 6.0.0+up6.7.0. - CI test-values for both charts now set clusterIssuer explicitly. A repo-wide grep confirms no chart carries a clusterIssuer default anymore.	2026-08-22 23:13:23 +02:00
jklein	cc6084ca58	Add install-test stage to the PR pipeline (k3d) ... New install-test job in validate-charts.yml: for exactly the charts a PR changes, install them into an ephemeral k3d cluster (pinned k3d v5.9.0, k3s v1.35.5-k3s1) and require every Deployment/StatefulSet to become Ready. Runs non-blocking (continue-on-error) during the stabilization phase. Fixtures live at the repo root under ci/ (not inside chart directories, so they neither trigger publishes on merge nor get packaged): a stub OnePasswordItem CRD, per-chart test values and fixtures (dummy secrets with in-cluster DSNs, throwaway postgres/redis/dex, synapse-generate seed job, static hostPath PVs where charts pin storage classes or need RWX), plus a shared ci/run-install-test.sh harness that also runs locally. Excluded with documented reasons (ci/excluded-charts.txt): satisfactory (multi-GB image), teamspeak-server (TS6 beta license expired, image crashes on start), template-chart (placeholder image). All 14 non-excluded charts verified locally in k3d using only the committed fixtures.	2026-08-21 23:12:38 +02:00