Check the deployed revision, not just any 200, in the health poll

/api/health now reports REVISION alongside status, and the CI wait
step checks for this deploy's own short SHA specifically - a stray
old container that never got torn down (or a build that silently
kept serving stale code) would still 200 on a plain health check but
now won't match.

.gitea/workflows/ci.yml

@@ -114,17 +114,21 @@ jobs:
       # (Type=simple, no readiness protocol) — not that `podman compose up
       # --build` actually finished and Puma is answering. Polls the health
       # endpoint (cube-host itself, same machine the container's port is
-      # published on) instead of trusting that. 5 minutes covers even a
+      # published on) instead of trusting that — checking for this
-      # from-scratch rebuild (Gemfile change, ~3.5 minutes measured) with
+      # deploy's own revision, not just any 200, so a stuck old container
-      # room to spare; a cached rebuild is normally up within a minute.
+      # that never got torn down can't pass as a successful deploy of the
+      # new one. 5 minutes covers even a from-scratch rebuild (Gemfile
+      # change, ~3.5 minutes measured) with room to spare; a cached
+      # rebuild is normally up within a minute.
       - name: Wait for it to come up
         run: |
+          expected=$(git rev-parse --short HEAD)
           for i in $(seq 1 30); do
-            if curl -sf http://localhost:4567/api/health >/dev/null; then
+            if curl -sf http://localhost:4567/api/health | grep -q "\"revision\":\"$expected\""; then
-              echo "Healthy after $(( (i - 1) * 10 ))s"
+              echo "Healthy at $expected after $(( (i - 1) * 10 ))s"
               exit 0
             fi
             sleep 10
           done
-          echo "::error::maptool did not become healthy within 5 minutes"
+          echo "::error::maptool did not report revision $expected within 5 minutes"
           exit 1

app.rb

@@ -169,7 +169,7 @@ module Maptool
     end
 
     get "/api/health" do
-      json status: "ok"
+      json status: "ok", revision: REVISION
     end
 
     get "/api/offline-tiles" do

docs/deployment.adoc

@@ -246,8 +246,11 @@ a retagged image's old layers behind — turning every deploy into a
 full `apt-get`/`bundle install` from scratch (~3 minutes measured,
 vs. ~20s before). Fixed by adding `--build` to the unit instead (see
 above); don't reintroduce the `podman rmi` step.
-. Polls `http://localhost:4567/api/health` (up to 5 minutes, the job
+. Polls `http://localhost:4567/api/health` for *this deploy's own*
-  fails if it never comes up) before calling the deploy done — the
+  revision (up to 5 minutes, the job fails if it never shows up)
-  restart above only confirms `podman compose up --build` was
+  before calling the deploy done — the restart above only confirms
-  launched (`Type=simple` has no readiness protocol), not that the
+  `podman compose up --build` was launched (`Type=simple` has no
-  build actually succeeded and Puma is answering.
+  readiness protocol), not that the build actually succeeded and the
+  new code is what's answering; checking the revision specifically,
+  not just any 200, also catches a stuck old container that never got
+  torn down.

test/test_app.rb

@@ -7,7 +7,7 @@ class AppTest < Minitest::Test
   def test_health
     response = request.get("/api/health")
     assert_equal 200, response.status
-    assert_equal({ "status" => "ok" }, json_body(response))
+    assert_equal({ "status" => "ok", "revision" => "dev" }, json_body(response))
   end
 
   def test_index_renders_with_asset_versioning_and_importmap