Add Forgejo CI for Homebrew tap audit #4

New issue

Closed

opened 2026-07-09 16:32:41 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 16:32:41 +00:00

Member

Problem

The active coilyco-flight-deck/homebrew-tap repo has a ward command surface but no Forgejo Actions workflow. .ward/ward.yaml exposes ward exec audit as brew audit --strict --tap coilyco-flight-deck/tap, so the canonical Forgejo repo should run that check automatically.

Do

Add a minimal .forgejo/workflows/ CI workflow for the tap.
Use the current AOS/dev-base workflow conventions used by the rest of the fleet where practical.
Run the repo's ward validation locally if Homebrew is available in the run image. If Homebrew is not available in the current dev-base, document the blocker and choose the smallest useful CI fallback, such as syntax/Formula file checks plus a follow-up.
Update docs only if the workflow surface is documented elsewhere in the repo.

Acceptance

The repo has a Forgejo Actions workflow on main that exercises the tap's audit surface or documents why that cannot run in the current image.
ward exec audit remains the canonical local command.
The change lands on Forgejo main.

## Problem The active `coilyco-flight-deck/homebrew-tap` repo has a ward command surface but no Forgejo Actions workflow. `.ward/ward.yaml` exposes `ward exec audit` as `brew audit --strict --tap coilyco-flight-deck/tap`, so the canonical Forgejo repo should run that check automatically. ## Do * Add a minimal `.forgejo/workflows/` CI workflow for the tap. * Use the current AOS/dev-base workflow conventions used by the rest of the fleet where practical. * Run the repo's ward validation locally if Homebrew is available in the run image. If Homebrew is not available in the current dev-base, document the blocker and choose the smallest useful CI fallback, such as syntax/Formula file checks plus a follow-up. * Update docs only if the workflow surface is documented elsewhere in the repo. ## Acceptance * The repo has a Forgejo Actions workflow on `main` that exercises the tap's audit surface or documents why that cannot run in the current image. * `ward exec audit` remains the canonical local command. * The change lands on Forgejo main.

coilyco-ops commented

2026-07-09 16:34:25 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-homebrew-tap-4 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T16:34:23Z). 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/homebrew-tap#4 · branch issue-4 · harness codex · workflow direct-to-main
Run: engineer-codex-homebrew-tap-4 · ward v0.493.0 · dispatched 2026-07-09T16:34:23Z
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.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-homebrew-tap-4` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T16:34:23Z). 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/homebrew-tap#4` · branch `issue-4` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-homebrew-tap-4` · ward `v0.493.0` · dispatched `2026-07-09T16:34:23Z` - **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.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 16:38:58 +00:00

tap: add Forgejo CI fallback

coilyco-ops closed this issue

2026-07-09 16:38:58 +00:00

coilyco-ops commented

2026-07-09 16:39:30 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: review gate skipped by --skip-review / --no-review-gate
summary: added .forgejo/workflows/ci.yml for the tap audit surface, with Ruby syntax checks over Formula/*.rb as the smallest useful fallback because brew is absent in the pinned image.
felt: straightforward, with the only real wrinkle being the missing Homebrew toolchain in the container image.
confidence: medium-high.
surprises: the local container had no brew or ruby, so YAML validation used an isolated venv.
follow-up: #5 tracks switching the workflow back to ward exec audit once the image includes Homebrew.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: review gate skipped by --skip-review / --no-review-gate summary: added `.forgejo/workflows/ci.yml` for the tap audit surface, with Ruby syntax checks over `Formula/*.rb` as the smallest useful fallback because `brew` is absent in the pinned image. felt: straightforward, with the only real wrinkle being the missing Homebrew toolchain in the container image. confidence: medium-high. surprises: the local container had no `brew` or `ruby`, so YAML validation used an isolated venv. follow-up: #5 tracks switching the workflow back to `ward exec audit` once the image includes Homebrew. </details>