Promote published releases without rebuilding their images #36

New issue

Open

opened 2026-11-01 20:11:53 +00:00 by viacheslavshuka · 0 comments

viacheslavshuka commented

2026-11-01 20:11:53 +00:00

Owner

Publishing a Forgejo release is the operator's production approval. Production must receive the retained image that already passed validation on development.

Scope

Create the release-publication workflow, prepared release notes, artifact eligibility checks, and production deployment verification. No second routine deployment approval is required.

Acceptance criteria

A reviewed release-preparation pull request sets the final version. Automation drafts notes from merged pull requests for operator review before publication.
Notes describe user-visible changes, breaking changes, and required operator actions. Draft creation does not authorize deployment.
Only publishing a matching Forgejo release triggers production promotion. A tag push or draft release alone cannot deploy.
The selected commit belongs to validated main and has the matching retained image. Missing images, missing validation, and mismatched version/commit/digest mappings block promotion.
Production uses the same image digest as the validated candidate. The workflow never silently rebuilds a missing artifact.
Fresh dependency and image vulnerability scans use current advisory data before promotion. Every vulnerability blocks regardless of severity or fix availability unless an exact reviewed exception applies. Exceptions need a reason and owner. Temporary vulnerability acceptance expires within thirty days. Expired exceptions and unavailable data block.
Production deployments serialize in explicit release order. A slow older deployment cannot overwrite a newer release.
Apply the candidate's committed migrations before starting dependent web or worker versions. Preserve every replaced version's active seven-day compatibility window.
Migration failure blocks rollout and preserves the existing compatible application. Do not restore the database automatically or report a partially migrated rollout as successful.
Success requires the correlated Dokploy result, readiness through the normal application entry point, and exact expected release identity.
Failed, canceled, timed-out, unhealthy, or wrong-identity deployments remain failed. Their redacted validation evidence stays associated with the retained release image.
Published release identity remains immutable. Note corrections can change prose without changing the version-to-artifact mapping.

Validation

Exercise draft creation, tag-only push, valid publication, missing image, mismatched digest, new vulnerability, expired exception, and wrong running identity. Confirm promotion preserves the original image digest and embedded version.

Exercise a release that requires an additive migration and a migration that fails. Verify application compatibility and that failure prevents dependent service rollout.

Dependencies

#34: Deploy validated main images to development. Production promotes the exact candidate validated on development.
#30: Block vulnerable dependencies and unsafe container configuration. Promotion reruns vulnerability checks with current advisory data.
#8: Apply PostgreSQL migrations with release compatibility checks. Production must execute candidate migrations and preserve active compatibility windows.

Publishing a Forgejo release is the operator's production approval. Production must receive the retained image that already passed validation on development. ## Scope Create the release-publication workflow, prepared release notes, artifact eligibility checks, and production deployment verification. No second routine deployment approval is required. ## Acceptance criteria - A reviewed release-preparation pull request sets the final version. Automation drafts notes from merged pull requests for operator review before publication. - Notes describe user-visible changes, breaking changes, and required operator actions. Draft creation does not authorize deployment. - Only publishing a matching Forgejo release triggers production promotion. A tag push or draft release alone cannot deploy. - The selected commit belongs to validated `main` and has the matching retained image. Missing images, missing validation, and mismatched version/commit/digest mappings block promotion. - Production uses the same image digest as the validated candidate. The workflow never silently rebuilds a missing artifact. - Fresh dependency and image vulnerability scans use current advisory data before promotion. Every vulnerability blocks regardless of severity or fix availability unless an exact reviewed exception applies. Exceptions need a reason and owner. Temporary vulnerability acceptance expires within thirty days. Expired exceptions and unavailable data block. - Production deployments serialize in explicit release order. A slow older deployment cannot overwrite a newer release. - Apply the candidate's committed migrations before starting dependent web or worker versions. Preserve every replaced version's active seven-day compatibility window. - Migration failure blocks rollout and preserves the existing compatible application. Do not restore the database automatically or report a partially migrated rollout as successful. - Success requires the correlated Dokploy result, readiness through the normal application entry point, and exact expected release identity. - Failed, canceled, timed-out, unhealthy, or wrong-identity deployments remain failed. Their redacted validation evidence stays associated with the retained release image. - Published release identity remains immutable. Note corrections can change prose without changing the version-to-artifact mapping. ## Validation Exercise draft creation, tag-only push, valid publication, missing image, mismatched digest, new vulnerability, expired exception, and wrong running identity. Confirm promotion preserves the original image digest and embedded version. Exercise a release that requires an additive migration and a migration that fails. Verify application compatibility and that failure prevents dependent service rollout. ## Dependencies - [#34: Deploy validated main images to development](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/34). Production promotes the exact candidate validated on development. - [#30: Block vulnerable dependencies and unsafe container configuration](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/30). Promotion reruns vulnerability checks with current advisory data. - [#8: Apply PostgreSQL migrations with release compatibility checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/8). Production must execute candidate migrations and preserve active compatibility windows. ## Related work - [#32: Use one application version across builds and release artifacts](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/32) - [#41: Recover failed deployments with a compatible previous image](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/41)

viacheslavshuka referenced this issue

2026-11-01 20:11:58 +00:00

Recover failed deployments with a compatible previous image #41

viacheslavshuka referenced this issue

2026-11-01 20:11:59 +00:00

Retain release images and redact CI evidence #42

viacheslavshuka referenced this issue

2026-11-01 20:12:00 +00:00

Rescan main dependencies and the production image daily #43

viacheslavshuka added the

kind

area/tooling