Watch
0
0
Fork
You've already forked hyperhive
0

hive-c0re: stop mirroring deploy tags to the forge (drop push_config)

Per the operator's ruling on #4851 (option (a)): the hive holds no
write identity on the forge, so the `push_config` mirror of an applied
repo's tags and `main` to `agent-configs/<name>` is removed, along with
its `run_config_push` helper and its call in `sync_agent`.

Docs and comments that described the mirror now say that forge `main`
advances only by an operator's merge.

Refs #4851
This commit is contained in:
atlas 2026-10-07 19:40:16 +02:00
commit 456a4511ab
6 changed files with 33 additions and 137 deletions

View file

@ -274,9 +274,9 @@ pub async fn create_container(name: &str, hive: &HiveEnv, paths: &AgentPaths) ->
/// (`job_queue::exec::run_purge_state`) — a later revive of the *same*
/// agent name is still a rebuild, not a first-spawn, so it lands here, not
/// in `provision_container`. Recover from `agent-configs/<name>` on the
/// forge when that's the case (kept current after every deploy by
/// `forge::push_config` — see `forge::fetch_config_main_into_applied`'s own
/// doc comment) rather than bailing outright. Deliberately **no fallback to
/// forge when that's the case (forge `main` is the last operator-merged
/// config — see `forge::fetch_config_main_into_applied`'s own doc comment)
/// rather than bailing outright. Deliberately **no fallback to
/// `proposed`**: that repo is seeded once at first spawn and never touched
/// again (`setup_proposed`'s own doc comment), so it can be arbitrarily
/// stale for a long-lived agent — restoring from it would silently revive