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).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 commit2e67d1b("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.2e67d1bmoved the deploy from the VM (which lackedfirebase-tools) to the CI runner, which is the right direction, but nothing generated/stored theFIREBASE_TOKENsecret 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:ciand 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 ownalways()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).