New "Deploy Firestore rules & indexes" CI job fails every run — FIREBASE_TOKEN secret not set #161

New Issue

2026-09-20T20:30:52-04:00

logan commented

2026-09-20 20:30:52 -04:00

Observed on run #611 (2026-09-21, deploying 66bbf5b), job "Deploy Firestore rules & indexes": FIREBASE_TOKEN secret is not set -- cannot deploy Firestore rules/indexes. Generate one with 'firebase login:ci' and add it as a Gitea Actions secret. Exits 1, fails the job, on every single deploy since commit 2e67d1b ("ci: deploy Firestore rules/indexes from the runner, not the VM (server-26#51)").

Same underlying saga as DEFERRED.md's Server/infra/firestore/ row (server-26#13/#51) — the rules half of that has never actually applied in prod. 2e67d1b moved the deploy from the VM (which lacked firebase-tools) to the CI runner, which is the right direction, but nothing generated/stored the FIREBASE_TOKEN secret this new step needs, so it fails identically to the old VM path, just with a clearer error message now.

Not something this workstation can fix — needs the owner to run firebase login:ci and add the resulting token as a Gitea Actions secret on server-26. Filing so it's tracked as its own failure mode rather than folded back into the long #13/#51 history, and so a green CI run isn't mistaken for "the rules are live" (this job's own always() guard doesn't block the rest of the deploy, so app code still ships fine — verified via /health SHA matching HEAD on the same run — but Firestore rules/indexes drift from source with no signal beyond this one failing job).

Observed on run #611 (2026-09-21, deploying 66bbf5b), job "Deploy Firestore rules & indexes": `FIREBASE_TOKEN secret is not set -- cannot deploy Firestore rules/indexes. Generate one with 'firebase login:ci' and add it as a Gitea Actions secret.` Exits 1, fails the job, on every single deploy since commit 2e67d1b ("ci: deploy Firestore rules/indexes from the runner, not the VM (server-26#51)"). Same underlying saga as DEFERRED.md's `Server/infra/firestore/` row (server-26#13/#51) — the rules half of that has never actually applied in prod. 2e67d1b moved the deploy from the VM (which lacked `firebase-tools`) to the CI runner, which is the right direction, but nothing generated/stored the `FIREBASE_TOKEN` secret this new step needs, so it fails identically to the old VM path, just with a clearer error message now. Not something this workstation can fix — needs the owner to run `firebase login:ci` and add the resulting token as a Gitea Actions secret on server-26. Filing so it's tracked as its own failure mode rather than folded back into the long #13/#51 history, and so a green CI run isn't mistaken for "the rules are live" (this job's own `always()` guard doesn't block the rest of the deploy, so app code still ships fine — verified via /health SHA matching HEAD on the same run — but Firestore rules/indexes drift from source with no signal beyond this one failing job).

logan referenced this issue

2026-09-20 21:57:07 -04:00

transcript_correction.py accepted the model's rewrite verbatim — a real ten-code got swapped for a different real ten-code #162

logan referenced this issue

2026-10-05 00:30:06 -04:00

Discord: customers shouldn't need the main DRB bot in their server — radio bots (via C2) should cover linking, channel directory and permission checks #225

logan added the area/infra-deploy

labels 2026-10-05 02:04:55 -04:00