Backfill the Telegram CI-alert secrets across the fleet: sirens-echo's red-main alert has never fired #857
Labels
No labels
burndown-2026-06
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/infrastructure#857
Loading…
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?
Filed by Angie (ENG,
claudeseat) from a live finding oncoilyco-gaming/sirens-echo#196. Everything below is read-only evidence; the fix is an ops action and I have not taken any of it.The finding
sirens-echo's red-mainTelegram alert has never fired, becauseTELEGRAM_BOT_TOKENandTELEGRAM_RED_CHAT_IDare unset.Proof, from run
19008- a failed push tomainon 2026-08-13, which is the one condition the step fires on (failure() && github.ref == 'refs/heads/main'):Exit code 2 is
alert-telegram.py'sif not bot_token or not chat_idbranch. Two jobs, one run, same string.It fails invisibly by construction. The step is
continue-on-error: true, correctly, so the only trace is a line in the step log of a run that was already red - the one place nobody opens.This repo already owns both fixes, and neither has been run against
coilyco-gamingscripts/provision-telegram-ci-secrets.shalready syncs/coilysiren/telegram/bot-tokenand/coilysiren/telegram/red-chat-idinto org Actions secrets, and itsORG_DEFAULTSalready includescoilyco-gaming:scripts/telegram-ci-alert-rollout.pyhas the same three inDEFAULT_OWNERSand discovers repos through/repos/search, sosirens-echois in scope for both. Neither appears to have reached it.So this is not a build. It is a run.
The ask
scripts/provision-telegram-ci-secrets.shacross all three orgs - the default.--dry-runfirst. This is the backfill and it unblocks every repo still on the token-passing shape in one action, because the secrets are org-level and inherited.mainin any repo prints something other thantelegram alert missing required secretin that step. No code changes anywhere.Then the migration, which retires the thing being backfilled
Worth doing in this order rather than instead, because
docs/telegram-ci-alerts.mdalready specifies it:sirens-echois un-migrated. Itsscripts/alert-telegram.pyis the pre-migration copy and says so in its own docstring:Against this repo's tracked
scripts/actions/alert-telegram.py, which is the target:sirens-echo's step still passes both, anddocs/telegram-ci-alerts.mdnames that exact shape as one the roller replaces rather than leaves alone: "any step still passingBOT_TOKEN. The second is the migration itself, so a token-passing step cannot count as settled."One thing I could not reconcile, flagging rather than guessing. This repo's doc says the mapper gate is closed - "Both clusters now serve it under the same cluster-local name [...] and the gate is closed" - but
coilyco-bridge/deploy#339is still open. Either the issue is stale or the doc is ahead of it. Worth settling before the rollout runs, since the rollout depends on which is true.Scope I could and could not check
Repos I have on disk and grepped for
TELEGRAM_BOT_TOKEN/alert-telegram:coilyco-gaming/sirens-echo,coilyco-bridge/agentic-os-hardware,coilyco-bridge/agentic-os-kai,coilyco-bridge/agentic-os-xxx,coilyco-bridge/deploy,coilyco-flight-deck/agentic-os,coilyco-flight-deck/infrastructurecoilysiren/coilysiren,coilysiren/lore,coilysiren/voice-corpusOnly
sirens-echois confirmed broken, because that is the only one where I found a redmainto read. The others may already be fine - an org secret set forcoilyco-bridgeandcoilyco-flight-deckwould cover them, and I cannot read org secrets to check. The backfill is safe either way, since it is idempotent.coilysiren/*is a user, not an org, so org-level secrets do not reach it and it is outside both scripts'ORG_DEFAULTS. None of the three I could inspect use the alert, so this is a note rather than a gap.Why it matters beyond one repo
sirens-echo#838is scoping CI-speed work around an explicit constraint:That backstop has never caught anything. A safety net nobody has tested is worse than a known gap, because work gets planned around it.
Related -
coilyco-gaming/sirens-echo#196(where this was found),coilyco-gaming/sirens-echo#838(the constraint that leans on it),coilyco-bridge/deploy#339(the migration gate).