Release process
A Suite release is an annotated release-candidate tag (v0.75.0-rc.1) on a commit of main,
and the apiome-suite image built from it, tagged with the designer package version. The
candidate ships only when four gates have run against that commit.
The gates
| # | Gate | Where | Automatic? |
|---|---|---|---|
| 1 | Suite build, designer lint and unit tests | Suite workflow (suite.yml) | Yes, on every push and pull request |
| 2 | Spire lint, pytest and the AI corpus report | The same workflow, spire-tests job | Yes |
| 3 | Studio E2E smoke against a real compose stack | Studio E2E workflow (studio-e2e.yml) | No — dispatched by hand at the tag |
| 4 | Cutover pre-flight: the cross-service token contract and the Spire interop check | docs/SUITE_AUTH_CUTOVER.md §3 | Partly |
Gates 1 and 2 already ran if the commit is on main
(gh run list --commit <sha> --workflow suite.yml). Gate 3 is the only automated check that
exercises the studio as a user does — Better Auth sign-in, the session cookie across the suite, a
studio-minted bearer that apiome-rest accepts, the canvas and the authoring conformance suites —
so it is required per tag, and the nightly run does not count: a schedule only ever runs on the
default branch, so it proves main at 07:00 UTC was green, not the tagged commit.
Run the E2E gate
workflow_dispatch takes a branch or tag, so tag first and aim the run at the tag:
git tag -a v0.75.0-rc.1 -m "RC1 candidate" <sha>
git push origin v0.75.0-rc.1
gh workflow run studio-e2e.yml --ref v0.75.0-rc.1
gh run list --workflow studio-e2e.yml --limit 5 \
--json databaseId,headSha,conclusion,event,url
The run's headSha must equal git rev-parse v0.75.0-rc.1^{commit} and its conclusion must be
success; the job writes a summary panel naming the ref and commit, so the run page is the artifact
to link. If it fails, fix forward, move the tag (delete and re-push it) and dispatch again. Failure
artifacts — screenshots, Playwright traces, the studio server log and the compose log — are uploaded
as studio-e2e-failure.
The nightly run
The same workflow runs at 07:00 UTC against main as rot detection. A red night opens (or comments
on) an issue labelled studio-e2e-nightly; the next green night closes it. GitHub disables scheduled
workflows in a repository with no activity for 60 days — re-enable it from Actions → Studio E2E
if the nightly stops appearing.
Checklist
Copy this into the candidate's release notes:
- [ ] Suite workflow green for the release SHA (build, designer lint, jest, spire tests)
- [ ] Studio E2E dispatched at the RC tag — run URL recorded, headSha matches, conclusion: success
- [ ] No open studio-e2e-nightly issue (or one triaged and explicitly waived, with the reason)
- [ ] Cutover pre-flight §3 run against the candidate, including the spire interop check
- [ ] designer/package.json version bumped, and the published image tag matches it
What a release contains
The published image carries the studio. Spire is run from source (uv) — there is no Spire image or
deploy workflow in the repository today — so a release that changes Spire's schema needs its
migrations applied as part of the rollout (Run Spire). The RC1 evidence
(docs/releases/RC1_EVIDENCE.md, August 2026) records the first battery: Slate promote and
rollback, the large-catalog build, tenant isolation and AI budget and audit passed; the
accessibility conformance run did not, and the candidate was held.