root/Jyotisha
1
0
Fork 0
Code Issues Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

fix: keep staging control plane on main

Browse Source
This commit is contained in:
Jesse_Chen
2026-07-21 04:19:26 +08:00
parent bd7c9830bb
commit 9e119df977
11 changed files with 100 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/superpowers/plans/2026-07-20-postgres-quality-gate-foundation.md
+4
View File
@@ -23,6 +23,10 @@
- Staging publication uses full Git SHA tags for discovery, but deployment is
authorized and pinned by the build outputs' `sha256` manifest digests. Never
deploy a mutable tag such as `latest`, or treat a tag alone as image identity.
- The `main` workflow revision is the trusted deployment controller. Target and
rollback SHAs must already be ancestors of reviewed `main`; their code is
represented by the digest-pinned images, but their validators and remote
orchestration scripts are never executed with staging Environment privileges.
- Finish each task with the focused commit shown.
## Planned Files
docs/superpowers/specs/2026-07-20-supabase-exit-backend-design.md
+1 -1
View File
@@ -182,7 +182,7 @@ touching the running application. After the operator runs the manual migration
workflow successfully, that workflow dispatches staging deployment again for the
same full SHA. The check may read the migration ledger but may never apply SQL.
Deployment and migration share one Actions concurrency group and one host-side lock covering live-tree synchronization through their final database/application verification. Deployment records the previous application SHA, image digests, and image IDs. It rejects stale or backward automatic revisions, verifies running container image IDs/RepoDigests plus the application-reported SHA, and requires public and private health checks before updating deployed-revision state. An older application revision requires an explicit manual rollback authorization; application rollback does not claim to roll back database state.
Deployment and migration share one Actions concurrency group and one host-side lock covering live-tree synchronization through their final database/application verification. The `main` controller owns manifest validation and remote orchestration: it requires a target SHA already present in reviewed `main` history, uploads only allowlisted controller files, and never executes deployment scripts from the target or rollback revision. Deployment records the previous application SHA, image digests, and image IDs. It rejects stale or backward automatic revisions, verifies running container image IDs/RepoDigests plus the application-reported SHA, and requires public and private health checks before updating deployed-revision state. An older application revision requires an explicit manual rollback authorization; application rollback does not claim to roll back database state.
## Automatic backend quality gate