read the running rev and the hyperhive flake from /etc files, not the unit
This commit is contained in:
parent
32af7e0639
commit
aed7c8451a
1 changed files with 416 additions and 85 deletions
|
|
@ -33,7 +33,10 @@ Where it runs and how it's enabled: [`services.md`](services.md#builder).
|
|||
with every input overridden:
|
||||
- `hyperhive` and `nixpkgs`: the sources the builder's own host was
|
||||
deployed with (`deploy.hyperhiveFlake`, `deploy.builder.nixpkgsFlake`). A hive's meta
|
||||
flake pins `hyperhive` by forge URL and rev instead.
|
||||
flake pins `hyperhive` by forge URL and rev instead. The builder reads the
|
||||
hyperhive path from `/etc/hyperhive/swarm-builder.json` in its container at
|
||||
the start of each build, so a deploy that changes only that source doesn't
|
||||
restart it or end a build in progress.
|
||||
- `agent`: `git+https://<forge>/agent-configs/<agent>?ref=refs/pull/<pr>/head&rev=<head>`.
|
||||
A build has one hour.
|
||||
4. The reply is the system closure's store path, or the last lines `nix`
|
||||
|
|
@ -160,6 +163,10 @@ running rev (`services.hyperhive.deploy.hive-controller.hyperhiveRev`, from `sel
|
|||
tree or a forge that can't answer leaves the pin. A merge to hyperhive's
|
||||
`main` moves nothing.
|
||||
|
||||
The controller reads its rev from `/etc/hyperhive/swarm-controller.json` at each
|
||||
render, not from its unit, so a deploy that changes no Rust doesn't restart it.
|
||||
A missing file, or one with no rev, counts as a controller without one.
|
||||
|
||||
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, and again every ten minutes while the latest
|
||||
|
|
|
|||
Loading…
Reference in a new issue