promote: dev → main (cutover fixes: sync-dev guard, owner-db hardening, post-deploy gate) #110

Merged

admin_emi merged 2 commits from dev into main

2026-07-26 07:29:34 +00:00

admin_emi commented

2026-07-26 07:29:07 +00:00

Owner

Promotes dev → main, deploying to beta (beta.thermograph.org).

Who merges. Centralis, once the required check is green — under the promotion policy main is the agent's call, and a promotion PR left open is worse than one never opened.

Divergence. 2 ahead, 6 behind. 2 commit(s) to carry, but the target has moved on by 6 — a merge commit is required and conflicts are possible
Not fast-forwardable: the target holds 6 commit(s) the source does not. That is the accumulated design of this release chain, not a mistake anyone just made — every promotion merges the source into the target, which creates a merge commit ON THE TARGET that the source never receives, so each promotion widens the gap it just closed. Expect --ff-only to fail with "diverging branches"; the promotion is a merge commit.

Predicted conflicts.

infra/deploy/RUNBOOK-vps1-vps2-cutover.md — edited on both sides
infra/deploy/db/provision-env-db.sh — edited on both sides
infra/deploy/deploy.sh — edited on both sides

Commits (2).

64986189 deploy.sh: honour TG_POST_DEPLOY on the compose path too (#109)
5c41ee4d provision-env-db: revoke PUBLIC connect on the owner database too (#108)

Merge with a merge commit, not a squash or a fast-forward. main runs ahead of dev from earlier promotions, so --ff-only fails with "diverging branches", and squashing would rewrite the shared history so the next promotion sees every prior commit as new. (Making promotions fast-forward-only is an open question, not current policy — it needs a one-time history reconciliation on the protected branches first.)

Promotes `dev` → `main`, deploying to beta (beta.thermograph.org). **Who merges.** Centralis, once the required check is green — under the promotion policy `main` is the agent's call, and a promotion PR left open is worse than one never opened. **Divergence.** 2 ahead, 6 behind. 2 commit(s) to carry, but the target has moved on by 6 — a merge commit is required and conflicts are possible Not fast-forwardable: the target holds 6 commit(s) the source does not. That is the accumulated design of this release chain, not a mistake anyone just made — every promotion merges the source into the target, which creates a merge commit ON THE TARGET that the source never receives, so each promotion widens the gap it just closed. Expect `--ff-only` to fail with "diverging branches"; the promotion is a merge commit. **Predicted conflicts.** - `infra/deploy/RUNBOOK-vps1-vps2-cutover.md` — edited on both sides - `infra/deploy/db/provision-env-db.sh` — edited on both sides - `infra/deploy/deploy.sh` — edited on both sides **Commits (2).** - 64986189 deploy.sh: honour TG_POST_DEPLOY on the compose path too (#109) - 5c41ee4d provision-env-db: revoke PUBLIC connect on the owner database too (#108) **Merge with a merge commit, not a squash or a fast-forward.** `main` runs ahead of `dev` from earlier promotions, so `--ff-only` fails with "diverging branches", and squashing would rewrite the shared history so the next promotion sees every prior commit as new. (Making promotions fast-forward-only is an open question, not current policy — it needs a one-time history reconciliation on the protected branches first.)

admin_emi added 2 commits 2026-07-26 07:29:08 +00:00