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

config PRs: remove the hive's config-PR webhook, poll and core merge

Browse source 
An operator's merge on the forge deploys a config PR through
swarm-controller's DeployRequest{rev}. The hive-side path that queued a
MergeConfigPr approval and merged the PR as `core` goes:

- the `/webhook/config-pr` receiver, its HMAC secret, the WebhookRegister
  boot node and the org-hook registration; the hive vhost's `/webhook/`
  location
- the 5-minute config-PR poll
- ApprovalKind::MergeConfigPr, its dashboard card, and the deploy DAG it
  drove (DeployWindow, MergeVerify, DeployApply, FinalizeDeploy,
  DeployTail), with verify_commit, the two-phase meta deploy, rollback
  refs, the PR-failure comment and forge/pr_merge.rs
- `fetched_sha`, `sha_short`/`pr_number` on approval events, and
  `sha`/`tag` on HelperEvent::ApprovalResolved: only the merge path set
  them

`config_repo`, `merged_pr_for_commit` and `post_pr_comment` move to
forge/pr_comment.rs for the merged-rev deploy's refusal comment.
Approvals v5 drops stored `merge_config_pr` rows; a test reopens a v4
database holding them.

Closes #4850
This commit is contained in:
atlas 2026-10-02 22:32:17 +02:00
commit efbfec6d01
39 changed files with 286 additions and 3199 deletions
Download patch file Download diff file Expand all files Collapse all files

18
swarm-controller/src/config_pr.rs
View file

@ -1,18 +1,15 @@
//! Swarm-level config-PR status, kept current by both a webhook nudge and a
//! periodic poll.
//!
//! `hive-c0re::forge::config_pr_poll` already scans `agent-configs/*` for
//! open PRs — but it does that once per hive, to queue that hive's own
//! `MergeConfigPr` approval, and nothing at swarm level reads the result.
//! swarm-ui's config-PR panel needs a *swarm*-level answer to "does agent X
//! have an open config PR" that does not depend on which hive currently
//! hosts X being reachable.
//!
//! Both paths write the same [`ConfigPrCache`]:
//!
//! - [`spawn`] — a periodic full rescan, mirroring `hive-c0re`'s own poll
//! shape. The backstop: catches anything a missed delivery loses, and is
//! what populates the cache before the first delivery ever arrives.
//! - [`spawn`] — a periodic full rescan. The backstop: catches anything a
//! missed delivery loses, and is what populates the cache before the first
//! delivery ever arrives.
//! - [`ConfigPrCache::apply_webhook_delivery`] — called from
//! `crate::webhook::post_webhook_forge` on a verified `ConfigPr` delivery.
//! The low-latency path: a PR opening or closing shows up immediately
@ -21,11 +18,6 @@
//! [`merged`] reads the same delivery for a merge, which the webhook handler
//! turns into a deploy. The poll has no counterpart: it lists open PRs only,
//! so a merge whose delivery is lost deploys nothing.
//!
//! Per mara's review call: ship both from the start rather than the poll
//! alone — the eventual swarm-level replacement for `hive-c0re`'s own
//! poll+webhook pair needs both anyway, so building only half here would be
//! work redone rather than work reused.
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
@ -119,9 +111,7 @@ struct WebhookRepository {
name: String,
}
/// How often to rescan `agent-configs/*`. Matches the interval named in
/// `hive-c0re::forge::config_pr_poll`'s own doc comment — same org, same
/// staleness tolerance, no reason for the two to disagree.
/// How often to rescan `agent-configs/*`.
const POLL_INTERVAL: std::time::Duration = std::time::Duration::from_mins(5);
/// The latest full scan, replaced atomically each cycle.