Loading
feat(e2e): the instance-configuration profile and its variant driver (instance-profile plan: 2/4)
Adds e2e/instance: the base environment, reconfigured and restarted per surface, so a row can assert behaviour that is a property of the running instance rather than of a repository. Includes the CI job and the docs.
Mechanism, verified on a real rig: write test/caproni/caproni.variant.yaml, caproni deploy --repo artifact-registry, gate on rollout status then the registry answering as itself, restore with {}. The chart puts checksum/config: sha256(.Values.appConfig) on the pod template, so a change through Helm rolls the pods by itself.
kubectl patch on that ConfigMap is deliberately not used: Helm 4 uses server-side apply, so a patch takes permanent SSA ownership of .data.config.yaml and the next caproni deploy and caproni up both fail — one patch wedges the rig until someone deletes the ConfigMap.
Measured: ~35s per config transition (2.7s deploy + 32s rollout + 1.5s settle). In 4 of 6 transitions the first ~1.5s after rollout status returned served the old config, which is why the behavioural gate follows it.
Justification for 1,303 insertions (guardrail 17). Splitting further would separate the driver from the only thing that proves it works. By file group: go non-test 579, docs 304, tests 234, scripts 98, CI 76, rig values 8.
Related to #1289
The implementation plan for this initiative is maintained out of tree by decision, so the (instance-profile plan: N/4) marker on this title names a plan that is not in the repository.