Point the fleet's homebrew tap at the Forgejo mirror via infra config (canonical stays GitHub) #440
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/infrastructure#440
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Decision
Kai (2026-07-02, director triage): the
homebrew-taprepo lives canonically on GitHub (public + PR-gated, matching the mirror doctrine), but the fleet should installwardfrom a Forgejo mirror of the tap, configured here in the infrastructure repo - not reach out togithub.comat install/build time.Why
Config-placement law: the tap repo is one thing, but which tap URL the fleet installs from is deployment config, so it lives in the infra layer, not baked and not a GitHub default. It also keeps the fleet build self-consistent - the
ward-specsbundle and release assets the formula overlays already resolve fromforgejo.coilysiren.me(aos, ward#453), so the tap source should too, taking GitHub off the fleet's runtime/build path.Scope
coilyco-flight-deck/homebrew-tap(canonical stays GitHub, the mirror syncs to fj).brewat the fj mirror URL for the fleet (the rollout, per the authoring-vs-rollout split - the tool is authored in the tap, the fleet-wide pointing is the ansible role).ward-specsresourceURL points at the aos Forgejo release asset (already the ward#453 checklist default).Related
ward#503 (the tap edit itself - the
ward-specsresource + overlay, lands canonically on GitHub), ward#453 / ward#441 (the swappable-bundle flip the tap overlays), ward#395 (the same infra-topology-externalization theme).Filed from the read-only director surface (she/her).
🔒 Reserved by
ward agent --driver claude— containerengineer-claude-infrastructure-440on hostkais-macbook-pro-2.localis carrying this issue (reserved 2026-07-02T17:59:39Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (2h0m0s TTL);--forceoverrides.— Claude (she/her), via
ward agentWARD-OUTCOME: done - infra config already tapped the fj mirror; landed the intent-lock + docs (group_vars headers, docs/ansible-homebrew-role.md, FEATURES.md) and filed #443 for the mirror provisioning.
This one turned out to be mostly archaeology. The literal ask - 'point the fleet's brew tap at the Forgejo mirror URL' - was already true in
group_vars/{mac,linux}.ymlsince June's tap-centralization (6abfae5). What was actually missing was the why: nothing recorded that the tap is GitHub-canonical and the fj URL is a deliberate config-placement choice, so a future edit could 'helpfully' repoint it at github.com. So the real deliverable became locking that intent (header comments) plus a docs section and a FEATURES entry.The thing that fought back, and the one I'm least comfortable with: the Forgejo
homebrew-taprepo is currentlymirror: false- a native repo, not a live pull mirror of GitHub. So scope item 1 ('a Forgejo mirror that syncs from GitHub') isn't genuinely satisfied yet, and it can't be from here - Forgejo sets pull-mirroring at migrate time, so it needs a destructive re-migrate on a repo the fleet installs from live. That's an operator wall, so I documented it and filed #443 rather than pull the trigger. Confidence in what landed (config + docs) is high; confidence that the end-to-end design works today is gated on #443.Two rough edges worth naming: the ward-specs
resourceconfirmation is a no-op until ward#503 lands that overlay (the formula's url/homepage/head already resolve from Forgejo). And pre-commit's pylint hook couldn't run - the container overlay is 100% full so uv can't build its ansible/botocore env - so I skipped just that one hook (diff is YAML+Markdown, zero Python); CI runs it clean.