vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

hive-c0re: stop mirroring deploy tags to the forge (drop push_config)

Browse source 
Per the operator's ruling on #4851 (option (a)): the hive holds no
write identity on the forge, so the `push_config` mirror of an applied
repo's tags and `main` to `agent-configs/<name>` is removed, along with
its `run_config_push` helper and its call in `sync_agent`.

Docs and comments that described the mirror now say that forge `main`
advances only by an operator's merge.

Refs #4851
This commit is contained in:
atlas 2026-10-07 19:40:16 +02:00
commit 456a4511ab
6 changed files with 33 additions and 137 deletions
Download patch file Download diff file Expand all files Collapse all files

19
docs/agent-lifecycle/config-changes.md
View file

@ -207,14 +207,13 @@ the submitter pushes again (or closes it) to retry.
### Forge mirror
The bundled `hive-forge` container runs on the swarm's forge host
(`deploy.forgejo.enable`, see [`../swarm/services.md`](../swarm/services.md)),
and hive-c0re mirrors every agent's applied repo into a
private `agent-configs` Forgejo org. `forge::push_config(<name>)` pushes
every tag, then `applied/main`, to `agent-configs/<name>` on every
startup sweep and every rebuild. Forge `main` is branch-protected, so
the forge routinely refuses a push of an established `main`, which
hive-c0re expects. Pushes are best-effort — a missing or stopped forge never
blocks a deploy.
(`deploy.forgejo.enable`, see [`../swarm/services.md`](../swarm/services.md)).
Every agent has a repo in the private `agent-configs` Forgejo org, created
and seeded by swarm-controller. hive-c0re pushes nothing to it: the
applied repo's tags (`deployed/0`) exist only locally, and forge `main`
advances only by an operator's merge. hive-c0re
reads from it — reseeding a purged `applied`, catching `applied` up, and
seeding `proposed` at first spawn.
Each agent is a **write collaborator on its own** `agent-configs/<name>`
repo — so it can push a branch and open a config PR — but not a member
@ -222,8 +221,8 @@ of any other agent's, so it can't reach another agent's config through
the forge. Branch protection keeps the agent off the `main` push
allowlist and allowlists merging to the `operators` team only, so an
agent can't fast-forward its own config or self-merge its PR (see
[Config changes](#config-changes) above). hive-c0re passes the tokenised
push URL inline to `git push`, never writing it into
[Config changes](#config-changes) above). hive-c0re passes the credential to
each `git` call inline, never writing it into
`applied/<n>/.git/config`; that repo is RO-bind-mounted into the root
agent, and a stored token would leak core's admin credential to an
agent.

4
docs/integrations/forge.md
View file

@ -70,9 +70,7 @@ Two things live in the `agent-configs` Forgejo organization:
`main` directly nor self-merge. An operator's merge in the Forgejo UI
deploys the merged commit (see
[config-changes.md § Config changes](../agent-lifecycle/config-changes.md#config-changes)).
hive-c0re never force-pushes: the `push_config` mirror pushes the
add-only status tags and `main` without force, and treats a refused
`main` push as expected.
hive-c0re pushes nothing to this org; it only reads from it.
Repos stay private, so an agent can't read another
agent's config. (Agents remain read-only collaborators on `core/meta`.)
hive-c0re also references this repo as the agent's **persistent meta