config PRs: document the operator merge, deploy only merges into main
docs: the config-repo `main` merge gate (merge = `core` + team `operators`, approvals = `operators`), the operator merge in the forge UI and what it deploys, the hand-added `operators` membership, and that with no eval-verify a failed rebuild leaves `applied/main` at the merged commit. The swarm README lists the converged gate and the merge deploy. `merged()` also requires `pull_request.base.ref == "main"`: the hive deploys its config repo's `main`, so a merge into another branch would only cost a forge fetch and a refusal comment (argus, #4894). Refs #4850
This commit is contained in:
parent
f1c695c212
commit
a5ea015bc6
4 changed files with 90 additions and 16 deletions
|
|
@ -71,11 +71,15 @@ Two things live in the `agent-configs` Forgejo organization:
|
|||
webhook at `/webhook/config-pr` queues a `MergeConfigPr` approval;
|
||||
`hive-c0re/src/forge/config_pr_poll.rs` re-scans every 5 minutes as a
|
||||
fault-tolerance backstop) — but
|
||||
`main` is branch-protected core-only: only hive-c0re's verify-and-ff-push
|
||||
merge handler lands on `main`, the operator team must approve first, and
|
||||
the agent can neither push `main` directly nor self-merge. `main` is
|
||||
fast-forward-only — hive-c0re never force-pushes (the merge handler's ff
|
||||
push lands fine; the `push_config` mirror pushes `main` + the add-only
|
||||
`main` is branch-protected: the merge whitelist is the `core` user
|
||||
(hive-c0re's merge of an approved `MergeConfigPr`) and the `operators`
|
||||
team (an operator merging in the Forgejo UI, which deploys the merged
|
||||
commit — see
|
||||
[approvals.md § Operator merge in the forge UI](../agent-lifecycle/approvals.md#operator-merge-in-the-forge-ui)),
|
||||
the approval whitelist is the `operators` team, and the agent can neither
|
||||
push `main` directly nor self-merge. hive-c0re's own merge is
|
||||
fast-forward-only, and hive-c0re never force-pushes (the
|
||||
`push_config` mirror pushes `main` + the add-only
|
||||
status tags without force, and treats a non-fast-forward rejection of
|
||||
`main` after a rolled-back deploy as expected — the forge keeps the
|
||||
approved history, the `failed/<id>` tag records the divergence).
|
||||
|
|
|
|||
Loading…
Reference in a new issue