Jinemi/thermograph

Fork 0

promote: dev → main (sign in with Google; shared OAuth engine) #127

Merged

admin_emi merged 3 commits from dev into main

2026-07-27 01:00:44 +00:00

admin_emi commented

2026-07-27 00:58:55 +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. 3 ahead, 14 behind. 3 commit(s) to carry, but the target has moved on by 14 — a merge commit is required and conflicts are possible
Not fast-forwardable: the target holds 14 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.

backend/tests/notifications/test_discord_login.py — modify/delete, git will stop here
CLAUDE.md — edited on both sides
backend/accounts/models.py — edited on both sides
backend/accounts/schemas.py — edited on both sides
backend/notifications/discord_link.py — edited on both sides
frontend/static/account.js — edited on both sides
frontend/static/style.css — edited on both sides
infra/deploy/thermograph.env.example — edited on both sides

Commits (3).

deb039ee accounts: sign in with Google, on a shared provider-agnostic OAuth engine (#122)
1d4defef BRANCHING: the escape hatch, now that apply_to_admins binds the owner too
890cb4a7 docs: the orchestrator runbook and the module map

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.** 3 ahead, 14 behind. 3 commit(s) to carry, but the target has moved on by 14 — a merge commit is required and conflicts are possible Not fast-forwardable: the target holds 14 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.** - `backend/tests/notifications/test_discord_login.py` — modify/delete, git will stop here - `CLAUDE.md` — edited on both sides - `backend/accounts/models.py` — edited on both sides - `backend/accounts/schemas.py` — edited on both sides - `backend/notifications/discord_link.py` — edited on both sides - `frontend/static/account.js` — edited on both sides - `frontend/static/style.css` — edited on both sides - `infra/deploy/thermograph.env.example` — edited on both sides **Commits (3).** - deb039ee accounts: sign in with Google, on a shared provider-agnostic OAuth engine (#122) - 1d4defef BRANCHING: the escape hatch, now that apply_to_admins binds the owner too - 890cb4a7 docs: the orchestrator runbook and the module map **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 3 commits 2026-07-27 00:58:56 +00:00

docs: the orchestrator runbook and the module map

PR build (required check) / changes (pull_request) Successful in 6s

Details

secrets-guard / encrypted (pull_request) Successful in 5s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

shell-lint / shellcheck (pull_request) Successful in 8s

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 1s

Details

890cb4a764

.claude/BRANCHING.md — how the trunk-based flow is actually run: the serialised
merge queue (Forgejo has no native one, so whoever orchestrates is it), the two
promotions and who decides each, and the hotfix down-merge that has to happen in
the same session or it becomes a regression scheduled for the next promotion.

Two things it states because getting them wrong is expensive here. CI does not
gate PRs into `release` — pr-build.yml fires only for dev and main — so a
required check on that branch would make every production promotion unmergeable
with a 405 naming no cause; closing that gap means changing the workflow first
and turning the requirement on second. And the chain cannot fast-forward: every
promotion leaves a merge commit on the target the source never receives, so
promotions are merge commits until someone deliberately reconciles the branches.

.claude/ownership.md — which tasks may run concurrently, seamed along the four
domains, plus the shared spine that has to be serialised: the workflows (CI
lives only in the root .forgejo/), env-topology.sh, the deploy entry points and
the CLAUDE.md files. Names the recurring collisions too — a schema change spans
alembic and whatever reads the column, and if the payload shape moves it is
PAYLOAD_VER and the frontend as well, which is one task and not two.

BRANCHING: the escape hatch, now that apply_to_admins binds the owner too

secrets-guard / encrypted (pull_request) Successful in 5s

Details

shell-lint / shellcheck (pull_request) Successful in 8s

Details

PR build (required check) / changes (pull_request) Successful in 13s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 1s

Details

secrets-guard / encrypted (push) Successful in 5s

Details

shell-lint / shellcheck (push) Successful in 7s

Details

1d4defefb9

Protection an admin walks through is documentation rather than a control, so
apply_to_admins goes on — but that removes the direct-push route for everyone,
including in an emergency, and the way back in should be written down before it
is needed rather than improvised.

There is no force flag; the supported route is lift the rule, act, restore it,
with both halves audited. Names the failure mode that actually justifies it: a
renamed status context makes the required check unsatisfiable, and with
apply_to_admins on that blocks every merge into dev and main with no exemption
for anyone.