Watch
0
0
Fork
You've already forked hyperhive
0
hyperhive/hive-host-sock
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas e2da5509ae swarm-ci-runner: run the forge CI runner as a swarm service
The CI runner was a hive deploy module: hive-ci.nix ran it beside the
forge, and hive-c0re registered it through the forge's admin API with
the `core` token, writing the registration token through hive-priv. It
could only run on the forge's host, and it kept an admin-scoped forge
token on a hive.

Now the runner is a swarm service:

- swarm-ci-runner.nix runs it in a `swarm-ci-runner` container on the
  host that sets deploy.ci-runner.enable, reaching the forge by name.
  It needs neither the forge nor a hive there.
- swarm-controller reads the forge's runner registration token with its
  own admin token and writes it to swarm/services/ci-runner/
  registration-token whenever it differs from what it last wrote. Its
  grant on that path is create/update only.
- The runner's own leaf (CN swarm-ci-runner, role and policy of the same
  name) reads that one path. swarm-bao-ci-runner.service fetches it into
  the runner's EnvironmentFile and restarts the runner on a change.
- A pre-start step removes .runner when the daemon's journal since its
  last start holds Forgejo's "unregistered runner" refusal (the daemon
  exits 1 when its startup Declare gets it), or when .runner names
  another forge address; upstream's pre-start step then registers again.

Removed from the hive side: hive-ci.nix and deploy.forgejo.ci.*,
forge/ci_runner.rs, PrivRequest::RegisterCiRunner and its handler and
ReadWritePaths entry, InfraContainer::Ci with hivectl's --ci and the
dashboard's hive-ci journal entry, HYPERHIVE_FORGE_CI_ENABLED, and
read:admin,write:admin from CORE_TOKEN_SCOPES: nothing else in hive-c0re
calls /api/v1/admin/*. The old ci options, under both swarm.forge.ci and
deploy.forgejo.ci, now fail evaluation naming deploy.ci-runner.

The forge's half of the old ci.enable, the actions/checkout mirror and
DEFAULT_ACTIONS_URL = self, is deploy.forgejo.actionsFromSelf.

Closes #4954
2026-10-05 13:55:37 +02:00
..
src swarm-ci-runner: run the forge CI runner as a swarm service 2026-10-05 13:55:37 +02:00
Cargo.toml hivectl: migrate dag_progress to hive-jobq-wire's generic GraphNode 2026-08-03 20:35:24 +02:00
README.md hive-c0re: remove the approvals subsystem 2026-10-04 23:55:32 +02:00

hive-host-sock

Wire types for the host admin socket (/run/hyperhive/host.sock) — the host-control protocol spoken between the hivectl operator CLI and the hive-c0re daemon.

Why it's its own crate

Re-homed out of hive-sh4re so a standalone hivectl depends on just this protocol crate instead of the whole daemon-shared crate. hivectl drives the full hive (spawn / kill / destroy / rebuild / deploy) over this socket without linking hive-c0re; keeping the request/response shapes here is what makes that thin dependency possible.

Shape

Serde-derived request/response enums for the host admin protocol. The larger shared payload type some variants reference (AgentStatusRow) stays in hive-sh4re — this crate is only the protocol envelope, no server or client implementation.

Its own jobs module is the exception: the job-queue vocabulary hivectl needs (Source, State, PermPayload, NodeId) is protocol-local. The typed DagView/NodeView projection that used to live there is gone — the queue is served as a generic graph (hive-jobq-wire), not as a second hand-written view.

See docs/trust-boundary/boundary.md (host admin socket access) for the trust model around who may connect to the socket, and hive-priv-sock for the sibling split on the privileged-helper socket.