vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

hive-c0re: a refused rev is an error log + Grafana alert, not a PR comment

Browse source 
A deploy request whose rev hive-c0re refuses (fetch failed, or the rev
does not descend from applied/main) no longer tries to comment on the PR
that merged it. Off the forge host that attempt always failed with "forge
core token absent". The refusal now logs at ERROR, message unchanged, and
the new `hh-config-rev-refused` Grafana rule fires on it.

Deleted with the posting: actions::post_rev_deploy_failure_to_pr, the
whole forge/pr_comment.rs (config_repo, merged_pr_for_commit,
post_pr_comment), and ReaderToken::value, whose only caller was
merged_pr_for_commit.

Refs #4851
This commit is contained in:
atlas 2026-10-09 21:53:17 +02:00 • committed by mara
commit 8c222f8910
9 changed files with 27 additions and 106 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/agent-lifecycle/config-changes.md
View file

@ -47,15 +47,15 @@ No MCP tool exists for config changes: opening the PR IS the request.
Otherwise it fetches the config repo's `main`, requires the commit to
descend from `applied/main`, fast-forwards `applied/main` to it, and
queues a rebuild. A failure before the rebuild (the fetch, or a commit
that doesn't descend) deploys nothing and posts the error as a comment
on the merged PR. An agent with no container on that hive yet ignores
that doesn't descend) deploys nothing and logs `swarm events: rev not
applied; nothing queued` at error, which fires the Grafana alert
`config rev refused`. An agent with no container on that hive yet ignores
the commit; its first deploy builds what it seeds.
This path runs **no eval-verify**. A merged config that doesn't
evaluate or build fails the rebuild, and `applied/main` stays at that
commit, so the agent's rebuilds keep failing until a fix merges. A
failed rebuild shows on the hive like any other and isn't commented on
the PR. A merge whose webhook delivery never reaches the controller
failed rebuild shows on the hive like any other. A merge whose webhook delivery never reaches the controller
deploys nothing.
Creating a brand-new agent is swarm-level (`swarmctl agent create`,

4
docs/integrations/forge.md
View file

@ -77,12 +77,8 @@ forge container:
- reseeding a purged `applied` repo, and the meta-update cascade's
fast-forward of `applied/main`
- seeding `proposed` from `agent-configs/<agent>` on first deploy
- finding the PR that merged a config commit the hive refused to deploy
- cloning and pulling `/knowledge`
Posting the refusal as a comment on that PR still needs the `core` token, so
only the forge host posts it.
Roll a change to any of this out store host first (its granter writes the
controller's grant on `swarm/hives/+/forge/token`), then the controller host,
then the hives. A hive that starts before its token exists reads with the