.gitea/workflows/deploy.yml

@@ -100,6 +100,28 @@ jobs:
           # Update compose files + mosquitto config
           git pull origin main
 
+          # server-26#51: Firestore rules + composite indexes had no deploy
+          # path and regressed silently after every fix (the alert_events and
+          # calls(org_id,started_at) indexes among them). The VM runs as the
+          # project service account, so firebase-tools authenticates via ADC
+          # with no key file, and infra/firestore/firebase.json pins database
+          # c2-server. Indexes go on additively -- no --force -- so a stray
+          # edit to firestore.indexes.json can never delete a live index;
+          # rules are a full replace, which is the intent. --non-interactive
+          # means the FIRST run after a drift still needs a one-time manual
+          # `firebase deploy` on the VM to clear pending deletions (it aborts
+          # rather than guess). A failure here warns but does NOT fail the
+          # deploy: a transient Firebase API error must not roll back a good
+          # app build.
+          if command -v firebase >/dev/null 2>&1; then
+            ( cd /opt/drb/infra/firestore \
+              && firebase deploy --only firestore:rules,firestore:indexes \
+                   --project ${{ secrets.FIREBASE_PROJECT_ID }} --non-interactive ) \
+              || echo "WARNING: firestore deploy failed (server-26#51) -- rules/indexes may be stale"
+          else
+            echo "WARNING: firebase CLI not on the VM -- skipped firestore deploy (server-26#51); install once with: npm i -g firebase-tools"
+          fi
+
           # server-26#65: capture what is actually live BEFORE switching, so
           # a bad deploy has something concrete to fall back to. This reads
           # from a state file rather than re-deriving it from git log,