|
2 | 2 |
|
3 | 3 | This is the checklist for publishing a SILO Console release. Pushing an |
4 | 4 | annotated `v*` tag starts `.github/workflows/release.yaml`; the workflow creates |
5 | | -a draft GitHub release and publishes the versioned and `latest` container tags. |
6 | | -The maintainer reviews and publishes the draft manually. |
| 5 | +a draft GitHub release and a versioned candidate image. It does not advance |
| 6 | +`latest`. The maintainer publishes the verified draft; `promote-image.yaml` |
| 7 | +then verifies the current stable release, signatures, SBOM, provenance and |
| 8 | +anonymous image access before promoting that digest to `latest`. |
| 9 | + |
| 10 | +This is the main-branch procedure as of 2026-09-13. Console v2.4.0 was built |
| 11 | +with the earlier workflow. Older assets do not acquire the new verification |
| 12 | +contract retroactively; see [release-contract.md](release-contract.md). |
7 | 13 |
|
8 | 14 | ## 1. Prepare one candidate commit |
9 | 15 |
|
@@ -61,19 +67,23 @@ Before GoReleaser runs, the tag workflow checks: |
61 | 67 | - that rebuilding `web-app/build` and `src/version.tsx` produces no diff. |
62 | 68 |
|
63 | 69 | GoReleaser then uploads binaries, archives, packages, checksums, legal files, |
64 | | -and a **draft** GitHub release. It publishes the multi-platform image directly |
65 | | -to `ghcr.io/pgsty/silo-console` under the release tag and `latest`. |
| 70 | +and a **draft** GitHub release. It publishes the multi-platform candidate image |
| 71 | +to `ghcr.io/pgsty/silo-console` under the release tag. The workflow verifies |
| 72 | +checksum/image signatures, SBOM attestations and provenance before declaring |
| 73 | +the draft ready. Only the separate post-publication workflow advances `latest`. |
66 | 74 |
|
67 | 75 | ## 4. Review and publish the draft |
68 | 76 |
|
69 | 77 | Review the generated notes and asset list, then publish the draft in GitHub. |
70 | | -The draft is the manual approval boundary; no separate environment or staging |
71 | | -package is required. |
| 78 | +After publication, require `promote-image.yaml` to succeed and verify anonymous |
| 79 | +pulls of both the release tag and `latest`. A published GitHub release alone |
| 80 | +is not proof that image promotion completed. |
72 | 81 |
|
73 | 82 | If GoReleaser fails while uploading assets, the release remains an unpublished |
74 | 83 | draft. Delete that partial draft and rerun the tag workflow. The container tags |
75 | | -may already point at the correctly labelled release image; rerunning with the |
76 | | -same tag replaces them with the completed build. |
| 84 | +for the candidate version may already exist. Retry only while the GitHub |
| 85 | +release is still a draft; the workflow refuses to overwrite a published release. |
| 86 | +`latest` stays at the previous verified release until promotion succeeds. |
77 | 87 |
|
78 | 88 | ## 5. Version metadata |
79 | 89 |
|
|
0 commit comments