Watch
0
0
Fork
You've already forked hyperhive
0

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

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

View file

@ -89,9 +89,12 @@
Git rev of the hyperhive checkout this host runs. hive-c0re pins
the generated meta flake's `hyperhive` input to
`git+<forge>/hyperhive/hyperhive.git?rev=<rev>`, and `nixpkgs`
follows that input. Wired by `nixosModules.default` from
follows that input. The swarm controller offers the same rev as the
`hyperhive` pin of `internal/meta`, which it takes when the rev is a
descendant of the committed pin. Wired by `nixosModules.default` from
`self.rev`, which a dirty tree does not have; with `null`,
hive-c0re refuses to render the meta flake.
hive-c0re refuses to render the meta flake and the controller leaves
the `internal/meta` pin where it is.
'';
};
agentBaseToplevel = lib.mkOption {