Studio release and deploy automation: publish and roll out the UI with every mecak8s release #1780

Parent: #1774. Picks up the "Helm/Ingress is a follow-up" note from #1736, and turns the standalone publish-studio job into part of the release train.

Scope

Every v* release of mecak8s must produce — and roll out — the matching Studio UI. Today publish-studio (from #1746) runs on the tag with needs: guard only: it is a sibling of the mecak8s image, not coupled to it, and nothing deploys it. The chart does not know Studio exists.

Release train coupling

• publish-studio joins the ordered train: the Helm chart job already gates on needs: [guard, publish-mecak8s] with "publish the chart only after its default image tag exists" — the same rule must hold for the Studio image the chart is about to reference.
• The Studio image is tagged and stamped from the same tag as mecated / mecatui / mecak8s, so ghcr.io/stacklok/mecatl/studio:vX.Y.Z always exists for the chart of the same version, signed and attested like its siblings (cosign keyless, SBOM attestation, SLSA provenance).
• The SDK coupling is the ordering risk to settle: Studio builds against the published @stacklok-oss/mecatl-sdk, so a release whose wire surface moved needs the SDK published before the Studio image is built. Decide whether the train enforces that, or whether Studio pins a known-good SDK range and lags by a release.

Chart and deploy surface

• Studio Deployment + Service + Ingress, running in external mode against the in-cluster mecak8s Service (MECATL_*), with STUDIO_PUBLIC_URL derived from the Ingress host (it decides the cookie flags and the single OAuth callback), the cookie/session sealing key from a Secret, and the OIDC settings shared with the daemon's.
• Image selection mirrors the existing convention exactly: studio.image.repository, a digest override, a tag, and the v<chart-version> fallback when both are cleared — so a chart release deploys the matching UI with no values edit.
• Kubernetes posture at parity with the mecak8s templates: PSS-compliant securityContext (note the Studio image is a Chainguard node runtime, not the 65532 static base — it needs its own non-root UID), readiness/liveness probes on the BFF health route, resource requests/limits, PDB, NetworkPolicy (Studio → mecak8s Service, Studio → IdP, nothing else), and imagePullSecrets support.
• Off by default (studio.enabled: false) so existing mecak8s installs are unaffected until they opt in.

Version-pin automation

• The release flow keeps Chart.yaml version/appVersion and image.tag aligned; the new studio.image.tag key joins that same pin set, including the cut-release skill's bump list and whatever checks assert the pins agree. A release must not be able to ship a chart whose Studio tag is stale.

Rollout

• How a running environment picks the new version up: GitOps auto-sync on the published chart version (Argo CD / Flux), a workflow_dispatch deploy job, or a values-bump PR from the release. This is the actual "automatic deploy" decision — the rest above only makes it possible.

Human decisions

• Studio as an optional part of the mecak8s chart, or its own chart at deploy/helm/studio published to the same OCI path? (one release artifact and one version vs independent lifecycles)
• Rollout mechanism: GitOps auto-sync, a deploy workflow, or a release-opened values PR? And which environment is the first target?
• Tag or digest in the chart default — digest is immutable and reproducible but needs a bump step; a tag rides the v<chart-version> fallback for free.
• Does the train enforce "SDK published before Studio image built", or does Studio pin an SDK range and accept lagging one release?
• Does Studio's Ingress terminate TLS itself, reuse the existing tls.* values, or sit behind a shared gateway?

Contract

docs/acceptance/studio-release-and-deploy.md (Architectural — it changes the release artifact set, the published chart's contract, and the deployment surface; the Studio-in-chart decision wants an ADR). Classified at plan time per docs/development-process.md.

Verification

helm lint and helm-unittest cases under deploy/helm/mecak8s/tests/ for the Studio templates (enabled/disabled, image selector precedence, v<chart-version> fallback, security profile, NetworkPolicy); deploy/helm/mecak8s/chart_test.go assertions for the new pins; task lint:actions; a kind install from values-kind.yaml reaching login → workspace against the in-cluster daemon; a workflow_dispatch release rehearsal proving the Studio image exists, verifies (cosign verify + gh attestation verify), and matches the chart's default; and a chart-version bump observed rolling the UI out end to end.