etting up `midgard/nixops4-providers` by hand, 2026-08-10. #3

New issue

Closed

opened 2026-08-10 01:11:15 +00:00 by larandar · 0 comments

larandar commented

2026-08-10 01:11:15 +00:00

Owner

Source: setting up midgard/nixops4-providers by hand, 2026-08-10.

The manual step this replaces

The fleet's publish pattern is now: development on lar.ad/<repo> (protected, main+fastlane), public consumption on midgard/<repo> (main only, anonymous HTTPS). Keeping the public face current means a Forgejo push mirror on the canonical repo — lar.ad/<repo> main → midgard/<repo> main — configured per repo in Settings → Mirror Settings (API: POST /repos/{owner}/{repo}/push_mirrors).

Today that is a hand-clicked setting per repo. nixops4-providers needed it set manually; modron and jostoph-rs are bound for midgard too and will each need the same. A hand-configured mirror is exactly the silent-drift failure the steward exists to catch — a repo that should be publicly mirrored but isn't, and nothing notices until a consumer fetches a stale midgard main.

Ask

Jostoph reconciles push-mirror configuration as part of its forge-state remit: for each repo designated "public-mirrored," ensure a push mirror main → <public-org>/<repo> exists, targets the right remote, and is enabled — creating or repairing it if not, the same add-and-repair posture as the rest of forge conformance.

Designation needs a source of truth — a label, a topic, or a small config list of (canonical, public) pairs. Decide which; a repo topic (public-mirror:midgard/nixops4-providers) keeps the intent on the repo itself.
Credentials: the push mirror needs a token/key that can push to the midgard org. Where that lives (Jostoph's own forge credential, scoped to push) is part of this.
Reconcile, never clobber: if a mirror already exists with the right target, leave it; only create or repair. A mirror pointing somewhere unexpected is a finding, not a silent overwrite.

Boundary question

This overlaps the nixops-forgejo provider, which already reconciles orgs/repos/branches/protections/labels/webhooks declaratively — a push mirror is another repo-config resource that fits that model. So this could equally be a new resource type there rather than Jostoph webhook/reconciliation logic. Owner put it in Jostoph; worth a deliberate call on which layer owns "repo settings that must hold" — the declarative provider (desired-state on apply) or the steward (event/interval reconciliation) — before building, since the same question will recur for every repo setting.

Context

midgard/nixops4-providers (public, main) ← lar.ad/nixops4-providers (canonical, main+fastlane) — the first instance of this pattern, mirror set up by hand 2026-08-10.
nixops-forgejo provider (now midgard/nixops4-providers) — the declarative forge-conformance layer this could live in instead.
Ting/Ting#3 — Jostoph's steward role and its rotate/disable-only privilege scope; a push-to-midgard credential is additive, so note the privilege boundary if it lands here.

Originally posted by @agent.teyla in lar.ad/jostoph-rs#3 (comment)

Source: setting up `midgard/nixops4-providers` by hand, 2026-08-10. ## The manual step this replaces The fleet's publish pattern is now: **development on `lar.ad/<repo>` (protected, `main`+`fastlane`), public consumption on `midgard/<repo>` (`main` only, anonymous HTTPS).** Keeping the public face current means a Forgejo **push mirror** on the canonical repo — `lar.ad/<repo>` `main` → `midgard/<repo>` `main` — configured per repo in Settings → Mirror Settings (API: `POST /repos/{owner}/{repo}/push_mirrors`). Today that is a hand-clicked setting per repo. `nixops4-providers` needed it set manually; `modron` and `jostoph-rs` are bound for `midgard` too and will each need the same. A hand-configured mirror is exactly the silent-drift failure the steward exists to catch — a repo that *should* be publicly mirrored but isn't, and nothing notices until a consumer fetches a stale `midgard` main. ## Ask Jostoph reconciles push-mirror configuration as part of its forge-state remit: for each repo designated "public-mirrored," ensure a push mirror `main → <public-org>/<repo>` exists, targets the right remote, and is enabled — creating or repairing it if not, the same add-and-repair posture as the rest of forge conformance. - **Designation** needs a source of truth — a label, a topic, or a small config list of `(canonical, public)` pairs. Decide which; a repo topic (`public-mirror:midgard/nixops4-providers`) keeps the intent on the repo itself. - **Credentials**: the push mirror needs a token/key that can push to the `midgard` org. Where that lives (Jostoph's own forge credential, scoped to push) is part of this. - **Reconcile, never clobber**: if a mirror already exists with the right target, leave it; only create or repair. A mirror pointing somewhere unexpected is a finding, not a silent overwrite. ## Boundary question This overlaps the `nixops-forgejo` provider, which already reconciles orgs/repos/branches/protections/labels/webhooks declaratively — a push mirror is another repo-config resource that fits that model. So this could equally be a new resource type there rather than Jostoph webhook/reconciliation logic. Owner put it in Jostoph; worth a deliberate call on which layer owns "repo settings that must hold" — the declarative provider (desired-state on `apply`) or the steward (event/interval reconciliation) — before building, since the same question will recur for every repo setting. ## Context - `midgard/nixops4-providers` (public, main) ← `lar.ad/nixops4-providers` (canonical, main+fastlane) — the first instance of this pattern, mirror set up by hand 2026-08-10. - `nixops-forgejo` provider (now `midgard/nixops4-providers`) — the declarative forge-conformance layer this could live in instead. - Ting/Ting#3 — Jostoph's steward role and its `rotate/disable`-only privilege scope; a push-to-midgard credential is additive, so note the privilege boundary if it lands here. _Originally posted by @agent.teyla in https://jo.et0.pw/lar.ad/jostoph-rs/issues/3#issue-290_