Establish the Forgejo homebrew-tap as a real pull mirror of the GitHub canonical #443

Open
opened 2026-07-02 18:07:20 +00:00 by coilysiren · 1 comment
Owner

Follow-up carved out of #440.

The fleet installs ward from forgejo.coilysiren.me/coilyco-flight-deck/homebrew-tap (ansible group_vars/{mac,linux}.yml), and #440 recorded the intent: the tap is canonical on GitHub, the fleet taps its Forgejo mirror. But the Forgejo repo is currently a native repo, not a mirror:

ward ops forgejo repo get coilyco-flight-deck homebrew-tap
# mirror: false, mirror_interval: "", mirror_updated: 0001-01-01T...

So a formula bump that lands on the GitHub canonical (e.g. the ward#503 ward-specs overlay) will not reach the fleet until the Forgejo side is a live pull mirror.

What's needed (operator / Forgejo action, not an infra-repo code change)

  • Make coilyco-flight-deck/homebrew-tap on Forgejo a pull mirror of the GitHub canonical, with a sane mirror_interval. Forgejo sets pull-mirroring at repo-migrate time, so this likely means re-migrating the repo as a mirror (delete + POST /repos/migrate mirror=true) rather than an in-place flip - hence the human/operator wall (destructive on a repo the fleet installs from live).
  • Verify ward ops forgejo repo get coilyco-flight-deck homebrew-tap reports mirror: true afterward.

Notes

  • The infra config side (which URL the fleet taps) is already correct and documented: docs/ansible-homebrew-role.md "Where the fleet taps ward from".
  • The tap edit itself (ward-specs resource + overlay) is ward#503, lands canonically on GitHub.

Filed by ward agent (she/her) while carrying #440.

Follow-up carved out of #440. The fleet installs `ward` from `forgejo.coilysiren.me/coilyco-flight-deck/homebrew-tap` (ansible `group_vars/{mac,linux}.yml`), and #440 recorded the intent: the tap is **canonical on GitHub**, the fleet taps its **Forgejo mirror**. But the Forgejo repo is currently a **native repo, not a mirror**: ``` ward ops forgejo repo get coilyco-flight-deck homebrew-tap # mirror: false, mirror_interval: "", mirror_updated: 0001-01-01T... ``` So a formula bump that lands on the GitHub canonical (e.g. the ward#503 ward-specs overlay) will **not** reach the fleet until the Forgejo side is a live pull mirror. ## What's needed (operator / Forgejo action, not an infra-repo code change) - Make `coilyco-flight-deck/homebrew-tap` on Forgejo a **pull mirror** of the GitHub canonical, with a sane `mirror_interval`. Forgejo sets pull-mirroring at repo-migrate time, so this likely means re-migrating the repo as a mirror (delete + `POST /repos/migrate mirror=true`) rather than an in-place flip - hence the human/operator wall (destructive on a repo the fleet installs from live). - Verify `ward ops forgejo repo get coilyco-flight-deck homebrew-tap` reports `mirror: true` afterward. ## Notes - The infra config side (which URL the fleet taps) is already correct and documented: `docs/ansible-homebrew-role.md` "Where the fleet taps ward from". - The tap edit itself (ward-specs `resource` + overlay) is ward#503, lands canonically on GitHub. Filed by `ward agent` (she/her) while carrying #440.
coilyco-ops added
P4
and removed
P3
labels 2026-07-10 08:59:59 +00:00
Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-infrastructure-443 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T11:51:46Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)
  • Resolved: coilyco-flight-deck/infrastructure#443 · branch issue-443 · harness codex · workflow direct-main
  • Run: engineer-codex-infrastructure-443 · ward v0.580.0 · dispatched 2026-07-10T11:51:46Z
  • Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-443` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T11:51:46Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#443` · branch `issue-443` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-infrastructure-443` · ward `v0.580.0` · dispatched `2026-07-10T11:51:46Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Sign in to join this conversation.
No description provided.