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

pin internal/meta's hyperhive on the controller's rev and rebuild agents when it moves

Browse source 
The swarm controller offers its own running rev (services.hyperhive.c0re.
hyperhiveRev) as the hyperhive pin of internal/meta and takes it only when
the forge compare API shows it descends from the committed pin; merges to
hyperhive main no longer move the pin, and the first commit pins main's head.
When a commit moves the pin, every placed agent gets a TriggerDeploy.

A deploy after a meta update no longer waits on it succeeding (after_any), so
a down builder does not hold back hives that render locally.
This commit is contained in:
atlas 2026-10-24 14:29:12 +02:00
commit 22e2d30581
10 changed files with 1027 additions and 148 deletions
Download patch file Download diff file Expand all files Collapse all files

36
docs/swarm/builder.md
View file

@ -125,14 +125,34 @@ lock doesn't wait for a build in progress and has ten minutes. The builder
commits nothing.
swarm-controller sends the request. It renders `internal/meta`'s `flake.nix`
with the same renderer hive-c0re uses (`hive-meta-flake`). The render pins
hyperhive to its forge `main`, and each custom agent that a hive places to its
`agent-configs/<agent>` `main`, all over `https`. The controller commits
`flake.nix` and the returned `flake.lock` to `internal/meta` in one commit, and
gives each hive's forge account read on the repo. It re-renders when it
starts, when hyperhive's `main` moves, before it deploys a merged config PR,
and before the first deploy of a new agent. That deploy waits for the commit.
A render equal to the committed `flake.nix` sends no lock.
with the same renderer hive-c0re uses (`hive-meta-flake`), all over `https`.
Each custom agent that a hive places pins to its `agent-configs/<agent>`
`main`. Hyperhive pins to one rev, a ratchet on the controller's own
running rev (`services.hyperhive.c0re.hyperhiveRev`, from `self.rev`):
- the first commit pins hyperhive's forge `main`;
- later, the pin moves to the controller's rev only when the forge's compare
API shows that rev is a strict descendant of the committed pin: commits
ahead of it, and none the pin has that it lacks. The compare endpoint counts
histories with no common ancestor as zero commits ahead, so the check needs
both directions;
- an older controller, a rev on another line, a controller built from a dirty
tree or a forge that can't answer leaves the pin. A merge to hyperhive's
`main` moves nothing.
The controller commits `flake.nix` and the returned `flake.lock` to
`internal/meta` in one commit, and gives each hive's forge account read on the
repo. It re-renders when it starts, before it deploys a merged config PR, and
before the first deploy of a new agent. Those deploys run whether or not the
update succeeded: a hive that builds from `internal/meta` does so only while it
pins the agent's current config (see
[Config changes](../agent-lifecycle/config-changes.md#the-swarms-meta-flake)). A render
equal to the committed `flake.nix` sends no lock.
When a commit moves the pin from one rev to another, the controller sends a
deploy to every agent a hive places, so they rebuild on the new hyperhive. A
restart that moves nothing deploys nothing, and the first commit deploys
nothing.
## Credentials