Watch
0
0
Fork
You've already forked hyperhive
0

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:
atlas 2026-10-02 19:27:16 +02:00
commit a5ea015bc6
4 changed files with 90 additions and 16 deletions

View file

@ -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).