From 4ad394204563cfdfb127a6360ae90437759cab29 Mon Sep 17 00:00:00 2001
From: S'Bussiso Dube <80188685+Sbussiso@users.noreply.github.com>
Date: Wed, 9 Sep 2026 14:19:22 -0700
Subject: [PATCH] =?UTF-8?q?Deploy=20from=20CI=20=E2=80=94=20fly.toml=20was?=
 =?UTF-8?q?=20a=20file=20that=20did=20nothing?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Deploy automation was deferred so a human could watch the first-ever
deploy of new infrastructure, with a note to automate once phase 1 was
stable. Phase 1 is stable, and leaving it deferred turned out worse than
what it avoided: fly.toml only took effect if someone remembered to run
`fly deploy` by hand.

That failed silently on 2026-09-09. A scale-to-zero change merged with
CI fully green and never reached Fly — the app kept running always-on,
and the config looked applied because the commit was on master. It was
only caught by checking the machine state directly. Config that silently
doesn't apply is more dangerous than no config, because it reads as done.

Deploy runs on push to master only, after BOTH matrix legs (sqlite and
postgres) pass — this service runs one codebase against either dialect,
so a green sqlite leg alone is not evidence a deploy is safe.

Two flags, each for a concrete reason:

  --strategy immediate  this app mounts sentinel_license_data, and the
                        default rolling strategy stands up a parallel
                        machine first, which errors on the volume's
                        single attachment slot.
  --ha=false            Fly otherwise provisions two machines. It did
                        exactly that on the manual deploy of the sibling
                        Sync service and the extra had to be scaled away
                        by hand; the volume could not serve two anyway.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .github/workflows/test.yml | 50 +++++++++++++++++++++++++++++++++-----
 1 file changed, 44 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 5e1247a..5d25613 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -1,10 +1,15 @@
-name: Test
+name: Test & Deploy
 
-# Deploy automation is deferred deliberately (see the Sentinel Command
-# plan doc, Phase 1: "fine to start with a manual `fly deploy` for the
-# very first cut given a human should be watching the first-ever deploy
-# of new infrastructure anyway; automate once phase 1 is stable"). This
-# workflow only covers lint + dependency audit + tests.
+# Tests on every push and PR; deploys to Fly on pushes to master.
+#
+# Deploy automation was deferred so a human could watch the first-ever
+# deploy of new infrastructure, with a note to "automate once phase 1 is
+# stable". Phase 1 is stable, and leaving it deferred created a worse
+# problem than it avoided: fly.toml became a file that did nothing. A
+# scale-to-zero change merged with CI green on 2026-09-09 and never
+# reached Fly — the app kept running always-on until someone noticed and
+# deployed by hand. Config that silently doesn't apply is more dangerous
+# than no config.
 
 on:
   push:
@@ -68,3 +73,36 @@ jobs:
         env:
           TEST_DATABASE_URL: ${{ matrix.test_database_url }}
         run: uv run pytest -v
+
+  deploy:
+    name: Deploy to Fly.io
+    runs-on: ubuntu-latest
+    # Waits on BOTH matrix legs (sqlite and postgres) — this service runs
+    # the same code against either dialect, so a green sqlite run alone
+    # is not evidence the deploy is safe.
+    needs: test
+    # Push-only: a PR runs the tests above but never ships.
+    if: github.event_name == 'push'
+    # Serialize so two quick pushes don't race on the machine update.
+    concurrency:
+      group: deploy-sentinel-license
+      cancel-in-progress: true
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: superfly/flyctl-actions/setup-flyctl@master
+
+      # --strategy immediate because this app mounts a volume
+      # (sentinel_license_data). The default rolling strategy tries to
+      # stand up a parallel machine first and errors on the volume's
+      # single attachment slot. Sentinel-Sync has no volume and so needs
+      # no override; Command Center has the same constraint and the same
+      # flag.
+      #
+      # --ha=false because Fly otherwise provisions TWO machines, which
+      # this service does not need and which the volume cannot serve
+      # anyway.
+      - name: flyctl deploy
+        run: flyctl deploy --remote-only --strategy immediate --ha=false --yes
+        env:
+          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}