2 Commits

Include renames

Author	SHA1	Message	Date
jakman85andClaude Opus 5	6586919132	fix(ci): CLUSTER_AVAILABLE=true would have FAKED A GREEN over 54 skipped tests ... Wiring L2/L3 into CI was a tracked next step, described in the plan as needing only vars.CLUSTER_AVAILABLE. Attempting it surfaced that the variable does not enable L2/L3 at all -- it only changes which way the stage fails, and before this commit one of those ways was a false pass. MEASURED, before the guard: CLUSTER_AVAILABLE=true ./ci/conformance.sh -> rc=0 "[junit] wrote skipped JUnit for 54 scaffolded test(s)" "[ ok ] L2/L3 conformance passed for touched subset" run.sh exits 0 in scaffold mode when it cannot reach a cluster, marking every test <skipped>. That is correct and honest FOR run.sh. It is catastrophic in ci/conformance.sh, which reaches that code only because the environment DECLARED a cluster available -- so it reported a pass over 54 tests that never executed. One Gitea variable away from a fake green on a gate that is now an ENFORCING required status check, and nothing caught it because nobody had ever set the variable. The CI runner holds no cluster credential by design (automountServiceAccountToken: false), so the local run this stage attempts can never succeed. The in-cluster trigger path that would make L2/L3 actually run is still unimplemented, and is blocked on a privilege- escalation design decision that is the operator's to make (plan section 4: any principal that can `create jobs` in ns conformance can run arbitrary code as the privileged conformance-runner SA, because Kubernetes places no `use` check on serviceAccountName). The stage now BLOCKS (exit 1) when a cluster is declared but every test skipped, which is what the merge-gate decision matrix already said should happen ("conformance skipped while CLUSTER_AVAILABLE=true -> BLOCK"). Verified: rc=1, naming the count and the reason. The plan document claimed CLUSTER_AVAILABLE was "the only remaining gate". Corrected in place with the measurement and an explicit do-not-set-this-yet. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 02:58:26 -05:00
jakman85andClaude Opus 4.8	d1a547fd15	docs(plan): L2/L3 conformance CI wiring plan; gate.yml placeholder -> plan pointer ... HAND-OFF 2 (L2/L3 conformance wiring) — DEFERRED with a concrete plan, per the hand-off's escape hatch (too risky to wire live cluster access from CI autonomously; do NOT hand CI a broad kubeconfig). The intended seam (in-cluster Chainsaw Job under its own scoped SA; CI holds only a narrow trigger credential) is mostly scaffolded but not safe to finish autonomously: - ci/conformance.sh still runs run.sh locally rather than triggering the in-cluster Job. - conformance/incluster/chainsaw-job.yaml has no repo-clone init-container and the stock chainsaw image lacks bash/python3/kubectl/git that run.sh needs. - No trigger SA/RBAC/credential exists, and the core blocker is a privilege-escalation design question: any `create jobs` credential in the conformance namespace can create a Job running as the privileged conformance-runner SA. This needs an admission constraint (recommended: narrow trigger SA + a Kyverno policy pinning the admissible Job shape), or a GitOps-native zero-credential trigger — an operator decision. - conformance/incluster/ isn't wired into Flux; Gitea vars/secrets aren't provisioned. docs/plans/l2-l3-conformance-ci-wiring.md captures current state, the security analysis, the functional gaps, a file-by-file step sequence, validation/rollback, and the open decisions. gate.yml's conformance placeholder now points to it (still if:false, honest). Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-08-31 09:01:18 -05:00