Fix Telegram CI alert action refs and reroll affected workflows #521

New issue

Closed

opened 2026-07-10 08:44:30 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 08:44:30 +00:00

Member

Current Forgejo CI is red across many repos because the Telegram alert rollout inserted a remote action ref that Forgejo runner resolves through GitHub incorrectly.

Evidence from the director scan on 2026-07-10:

66 repos scanned across coilyco-flight-deck, coilyco-bridge, coilyco-gaming, and coilysiren.
21 repos currently have a latest failed Actions task.
Readable failed logs show the same runner setup failure before the real job steps run:
failed to read action 'Alert Telegram on main failure', no files found after reading paths: action.yml, action.yaml, Dockerfile
Example failed runs:
Those logs show Forgejo runner fetching https://github.com/coilyco-flight-deck/agentic-os for the reusable action. The GitHub mirror documented in agentic-os/docs/mirror-to-github.md is coilysiren/agentic-os, so uses: coilyco-flight-deck/agentic-os/actions/telegram-alert@main is the wrong remote ref for consumer repos.

Likely fix:

In scripts/telegram-ci-alert-rollout.py, change ACTION_REF_REMOTE from coilyco-flight-deck/agentic-os/actions/telegram-alert@main to the GitHub mirror ref that actually resolves, coilysiren/agentic-os/actions/telegram-alert@main.
Update scripts/test_telegram_ci_alert_rollout.py and docs/telegram-ci-alerts.md to match.
Rerun the rollout in execute mode so already-mutated workflows are rewritten. The current mutator returns early when Alert Telegram on main failure is present, so it may also need to replace stale alert blocks rather than treating them as idempotently correct.
Verify at least one affected repo has the corrected uses: line after rollout.

Acceptance:

Infrastructure tests for the rollout mutator pass.
Affected workflows no longer contain uses: coilyco-flight-deck/agentic-os/actions/telegram-alert@main.
Affected workflows use uses: coilysiren/agentic-os/actions/telegram-alert@main, except coilyco-flight-deck/agentic-os itself, which should continue using the local ./actions/telegram-alert path.
The latest Forgejo Actions failures caused only by action resolution are cleared by rerunning or by new main runs after the corrected rollout lands.

Current Forgejo CI is red across many repos because the Telegram alert rollout inserted a remote action ref that Forgejo runner resolves through GitHub incorrectly. Evidence from the director scan on 2026-07-10: - 66 repos scanned across `coilyco-flight-deck`, `coilyco-bridge`, `coilyco-gaming`, and `coilysiren`. - 21 repos currently have a latest failed Actions task. - Readable failed logs show the same runner setup failure before the real job steps run: `failed to read action 'Alert Telegram on main failure', no files found after reading paths: action.yml, action.yaml, Dockerfile` - Example failed runs: - https://forgejo.coilysiren.me/coilyco-flight-deck/backend/actions/runs/49 - https://forgejo.coilysiren.me/coilyco-flight-deck/galaxy-gen/actions/runs/32 - https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/actions/runs/979 - https://forgejo.coilysiren.me/coilyco-gaming/eco-app/actions/runs/93 - Those logs show Forgejo runner fetching `https://github.com/coilyco-flight-deck/agentic-os` for the reusable action. The GitHub mirror documented in `agentic-os/docs/mirror-to-github.md` is `coilysiren/agentic-os`, so `uses: coilyco-flight-deck/agentic-os/actions/telegram-alert@main` is the wrong remote ref for consumer repos. Likely fix: - In `scripts/telegram-ci-alert-rollout.py`, change `ACTION_REF_REMOTE` from `coilyco-flight-deck/agentic-os/actions/telegram-alert@main` to the GitHub mirror ref that actually resolves, `coilysiren/agentic-os/actions/telegram-alert@main`. - Update `scripts/test_telegram_ci_alert_rollout.py` and `docs/telegram-ci-alerts.md` to match. - Rerun the rollout in execute mode so already-mutated workflows are rewritten. The current mutator returns early when `Alert Telegram on main failure` is present, so it may also need to replace stale alert blocks rather than treating them as idempotently correct. - Verify at least one affected repo has the corrected `uses:` line after rollout. Acceptance: - Infrastructure tests for the rollout mutator pass. - Affected workflows no longer contain `uses: coilyco-flight-deck/agentic-os/actions/telegram-alert@main`. - Affected workflows use `uses: coilysiren/agentic-os/actions/telegram-alert@main`, except `coilyco-flight-deck/agentic-os` itself, which should continue using the local `./actions/telegram-alert` path. - The latest Forgejo Actions failures caused only by action resolution are cleared by rerunning or by new main runs after the corrected rollout lands.

coilyco-ops commented

2026-07-10 08:45:26 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T08:45:25Z). 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#521 · branch issue-521 · harness codex · workflow direct-main
Run: engineer-codex-infrastructure-521 · ward v0.569.0 · dispatched 2026-07-10T08:45:25Z
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.569.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-521` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:45:25Z). 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#521` · branch `issue-521` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-infrastructure-521` · ward `v0.569.0` · dispatched `2026-07-10T08:45:25Z` - **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.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 08:52:27 +00:00

fix: reroll Telegram alert mirror ref

coilyco-ops closed this issue

2026-07-10 08:52:27 +00:00

coilyco-ops referenced this issue

2026-07-10 08:52:54 +00:00

Inline Telegram CI alerts instead of depending on the stale GitHub action mirror #522

coilyco-ops commented

2026-07-10 09:03:46 +00:00

Author

Member

WARD-OUTCOME: done

details

review summary: skipped.
workflow: direct-to-main; review summary: skipped by ~/.ward/config.yaml default.
felt: straightforward, with one merge from origin/main after the rollout push.
confidence: high.
surprises: the rollout commit landed first, then main advanced and needed a merge.
follow-ups: none.

WARD-OUTCOME: done <details><summary>details</summary> review summary: skipped. workflow: direct-to-main; review summary: skipped by ~/.ward/config.yaml default. felt: straightforward, with one merge from origin/main after the rollout push. confidence: high. surprises: the rollout commit landed first, then main advanced and needed a merge. follow-ups: none. </details>