Inline remaining Telegram alert steps so CI can prepare workflows #416

New issue

Closed

opened 2026-07-10 05:34:51 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-10 05:34:51 +00:00

Member

Problem

CI is still failing during workflow preparation with:

failed to read action 'Alert Telegram on main failure', no files found after reading paths: action.yml, action.yaml, Dockerfile

agentic-os#411 partially fixed this by adding actions/telegram-alert and inlining some alert steps, but current Forgejo main still contains local action uses in the front test jobs:

.forgejo/workflows/release.yml job test still has uses: ./actions/telegram-alert.
.forgejo/workflows/mirror-to-github.yml job test still has uses: ./actions/telegram-alert.

The failing runner log shows workflow preparation fetching https://github.com/coilyco-flight-deck/agentic-os at main before actions/checkout executes. That GitHub mirror is stale at 4dbb587ebb5d0438cd7b7f88d69fa5acb2d6c794, while Forgejo canonical main is e9ea33bd75ca72d59a1ea8edde14017f5a487816. Even if the mirror catches up, the failure path should not depend on a local action that Forgejo resolves before checkout.

Requested change

Remove every remaining uses: ./actions/telegram-alert from AOS workflows. Inline the small Telegram alert run: block everywhere, or invoke a checked-in script only after checkout in a way Forgejo-runner does not resolve as an action during workflow preparation.

Also grep all workflows for telegram-alert and Alert Telegram on main failure to ensure no prep-time local action remains.

Validation

rg "uses: \./actions/telegram-alert|telegram-alert" .forgejo/workflows should return no prep-time local action use.
Trigger or inspect a PR CI run and confirm actions/checkout@v6 actually executes before any failure alert path.
Keep TELEGRAM_BOT_TOKEN and TELEGRAM_RED_CHAT_ID as secrets and do not print them.

## Problem CI is still failing during workflow preparation with: ```text failed to read action 'Alert Telegram on main failure', no files found after reading paths: action.yml, action.yaml, Dockerfile ``` `agentic-os#411` partially fixed this by adding `actions/telegram-alert` and inlining some alert steps, but current Forgejo `main` still contains local action uses in the front test jobs: * `.forgejo/workflows/release.yml` job `test` still has `uses: ./actions/telegram-alert`. * `.forgejo/workflows/mirror-to-github.yml` job `test` still has `uses: ./actions/telegram-alert`. The failing runner log shows workflow preparation fetching `https://github.com/coilyco-flight-deck/agentic-os` at `main` before `actions/checkout` executes. That GitHub mirror is stale at `4dbb587ebb5d0438cd7b7f88d69fa5acb2d6c794`, while Forgejo canonical `main` is `e9ea33bd75ca72d59a1ea8edde14017f5a487816`. Even if the mirror catches up, the failure path should not depend on a local action that Forgejo resolves before checkout. ## Requested change Remove every remaining `uses: ./actions/telegram-alert` from AOS workflows. Inline the small Telegram alert `run:` block everywhere, or invoke a checked-in script only after checkout in a way Forgejo-runner does not resolve as an action during workflow preparation. Also grep all workflows for `telegram-alert` and `Alert Telegram on main failure` to ensure no prep-time local action remains. ## Validation * `rg "uses: \./actions/telegram-alert|telegram-alert" .forgejo/workflows` should return no prep-time local action use. * Trigger or inspect a PR CI run and confirm `actions/checkout@v6` actually executes before any failure alert path. * Keep `TELEGRAM_BOT_TOKEN` and `TELEGRAM_RED_CHAT_ID` as secrets and do not print them.

coilyco-ops commented

2026-07-10 05:35:06 +00:00

Author

Member

Dispatch attempt from the read-only director surface failed:

/bin/bash: line 1: /usr/local/bin/warded: cannot execute: required file not found

This is the same surface launcher blocker filed as coilyco-flight-deck/ward#951. The issue is captured, but no sibling engineer was started from this surface.

Dispatch attempt from the read-only director surface failed: ```text /bin/bash: line 1: /usr/local/bin/warded: cannot execute: required file not found ``` This is the same surface launcher blocker filed as coilyco-flight-deck/ward#951. The issue is captured, but no sibling engineer was started from this surface.

coilyco-ops commented

2026-07-10 05:43:01 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-416 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T05:43:01Z). 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/agentic-os#416 · branch issue-416 · harness codex · workflow direct-main
Run: engineer-codex-agentic-os-416 · ward v0.555.0 · dispatched 2026-07-10T05:43:01Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T05:35:06Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-416` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T05:43:01Z). 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/agentic-os#416` · branch `issue-416` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-agentic-os-416` · ward `v0.555.0` · dispatched `2026-07-10T05:43:01Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:35:06Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 05:45:57 +00:00

fix(workflows): inline Telegram alerts

coilyco-ops closed this issue

2026-07-10 05:45:57 +00:00

coilyco-ops commented

2026-07-10 05:47:12 +00:00

Author

Member

WARD-OUTCOME: done

details

workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)
retrospective: The fix was straightforward. The only real wrinkle was Forgejo prep-time action resolution, so the inline Python alert block was the safe path.
confidence: high
surprises: None after the workflow grep confirmed only the two local action uses remained.
follow-ups: None.

WARD-OUTCOME: done <details><summary>details</summary> workflow: direct-to-main; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) retrospective: The fix was straightforward. The only real wrinkle was Forgejo prep-time action resolution, so the inline Python alert block was the safe path. confidence: high surprises: None after the workflow grep confirmed only the two local action uses remained. follow-ups: None. </details>