| Filename | Latest commit message | Latest commit date |
|---|---|---|
e2da5509ae
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 |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hivectl
The operator-facing host CLI. A thin client for the hive-c0re
daemon — speaks the host admin socket protocol (hive-host-sock) and
does not link the daemon crate. Container lifecycle and the
matrix/gateway verbs all forward to the daemon and need it running; a few (wg/peer-config, choom) work off local
host state instead.
When to use it
Reach for this crate when adding an operator-run host command — agents
talk to the daemon over their own MCP tool surface
(hive-agent-mcp), not this binary. hivectl is what a human operator
(or a host-side script) runs.
Shape
One module per subcommand family; main.rs is just the clap parse +
dispatch:
agents.rs— container lifecycle for an EXISTING agent (start/stop/kill/rebuild/restart/…); creation is swarm-level (swarmctl agent create).dag_progress.rs— rebuild-queue progress rendering.power.rs— restart/start/stop at the container level.choom.rs— drop into an interactive claude session in a container.forge.rs— reconciles an agent's config against its forge repo.matrix.rs— invite a matrix user to the hive Space or a room.gateway.rs— gateway Basic-auth user management (htpasswd).wg.rs— WireGuard mesh helpers.subvol.rs— btrfs state-subvolume ops.quota.rs,util.rs,completions.rs,open.rs— shared helpers, shell completions, browser-open.
Full verb reference: docs/tools/hivectl.md.