Task · GCV-0041

Provision pinned envtest assets in hosted CI so the admission gate can run there

Description

The admission harness is deliberately part of just check rather than a heavy ci leg, and check is what the hosted Validate public reference workflow runs byte for byte. That workflow installs ripgrep, Go and just and nothing else. KUBEBUILDER_ASSETS is asserted only in just setup, which CI never calls. The harness is correctly forbidden from skipping when its binaries are absent, so the moment the wiring pass adds it to scripts/validate.sh the hosted run goes red and GCV-0034 cannot satisfy its second Definition of Done item. Nothing in waves 1 to 4 covered this because the harness was never wired in. controller-tools publishes the binaries as release assets on the exact tag the justfile renovate annotation already tracks, each with a published sha512 sidecar, so the provisioning is pinned and checksum-verifiable without hand-transcribing anything.

Acceptance Criteria

Definition of Done

Implementation Plan

Wave 5: provision linux-amd64 envtest assets in the hosted Validate workflow from the justfile pin; verify the release sidecar checksum and fail-closed control; root lands provisioning with harness wiring in one commit and confirms admission ran in hosted logs.

Implementation Notes

Wave 5 hosted run 34277495122 derived envtest 1.37.0 from the justfile, verified the Linux amd64 archive against its same-release sha512 sidecar, reported kube-apiserver Kubernetes v1.37.0 and etcd 3.7.0, exported KUBEBUILDER_ASSETS, and passed just check with 19 admission passes and one explicit-null leaf skipped. The corrupt-archive control failed loudly at checksum verification. Provisioning and harness wiring landed together in 510de1c193c00795d95448a705964707d1aad81f.

Final Summary

Wave 5 provisioned checksum-verified envtest assets from the sole justfile pin and proved the admission gate runs in hosted CI at the integration SHA.

View the source file on GitHub