promote: dev → main #131
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Jinemi/thermograph#131
Loading…
Reference in a new issue
No description provided.
Delete branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Promotes
dev→main, deploying to beta (beta.thermograph.org).Who merges. Centralis, once the required check is green — under the promotion policy
mainis the agent's call, and a promotion PR left open is worse than one never opened.Divergence. 5 ahead, 0 behind. 5 commit(s) to carry, and the target has nothing of its own
Fast-forwardable: the target has no commits of its own to preserve.
Predicted conflicts. None: no file was touched on both sides since the branches parted.
Commits (5).
2776a6cdMerge pull request 'openbao: add a dormant OpenBao backend alongside SOPS' (#130) from openbao-backend into dev1941b184Merge dev into openbao branch (dev moved when #128 landed)8a2c8386forgejo: restart the db service on a clean exit, not just on failure7878763bforgejo: restart the db service on a clean exit, not just on failure6bd07d33openbao: add a dormant OpenBao backend alongside SOPSMerge with a merge commit, not a squash or a fast-forward.
mainruns ahead ofdevfrom earlier promotions, so--ff-onlyfails 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.)forgejo_db has been at 0/1 replicas since 2026-07-29 01:24 UTC. Postgres hit an invalid data-directory lock file ("could not open file postmaster.pid ... performing immediate shutdown because data directory lock file is invalid") and exited 0. With restart_policy.condition=on-failure, Swarm read the zero status as successful completion, marked the task Complete, and never rescheduled it. The forgejo service itself stayed Up and kept serving its homepage, so the outage presented as every repository page, the whole API and all CI returning 500 with "dial tcp: lookup db on 127.0.0.11:53: no such host" — including the auth path, which is why API calls reported "user does not exist [uid: 0]" rather than a database error. on-failure cannot distinguish "finished successfully" from "shut itself down and should be restarted", and Postgres exits 0 on several such paths, so it is the wrong policy for an always-on stateful service. This is the durable fix; it does not restart the currently stopped task.forgejo_db has been at 0/1 replicas since 2026-07-29 01:24 UTC. Postgres hit an invalid data-directory lock file ("could not open file postmaster.pid ... performing immediate shutdown because data directory lock file is invalid") and exited 0. With restart_policy.condition=on-failure, Swarm read the zero status as successful completion, marked the task Complete, and never rescheduled it. The forgejo service itself stayed Up and kept serving its homepage, so the outage presented as every repository page, the whole API and all CI returning 500 with "dial tcp: lookup db on 127.0.0.11:53: no such host" — including the auth path, which is why API calls reported "user does not exist [uid: 0]" rather than a database error. on-failure cannot distinguish "finished successfully" from "shut itself down and should be restarted", and Postgres exits 0 on several such paths, so it is the wrong policy for an always-on stateful service. This is the durable fix; it does not restart the currently stopped task.