ci: check the generated code; deploy: migrate before the switch

Two of Serverpod's own conventions, as its v4 project template and roles have them.

CI now runs `serverpod generate` (CLI pinned to the server's Serverpod version, like
the template's workflow) and fails if the committed generated code differs from its
output, so a model or endpoint changed without regenerating can't reach main. Checked in
a clean clone: today's code passes, a committed stale generated file fails.

redeploy.sh now applies the migrations in a run of their own, with Serverpod's
maintenance role (--role=maintenance --apply-migrations), after the dump and before
switching to the new server. That run exits with 0 only if the migrations worked, and
each migration is one transaction, so a failing one stops the deploy while the old
server keeps serving; before, the new server applied them at start and would have
crash-looped. Tested on the local stack: a deploy through the new step, and a failing
run (wrong database password) that exits with 1 after six attempts. AGENTS.md says
migrations must keep the old server working until the switch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

deploy/compose.yaml

@@ -42,7 +42,8 @@ services:
     image: halkyon-learn-server
     restart: unless-stopped
     # Applies pending migrations at every start, then serves. One instance only, so
-    # no two servers ever migrate at once.
+    # no two servers ever migrate at once. (On learn.halkyon.eu, deploy/redeploy.sh has
+    # applied them in a run of their own before, so nothing is left to do here.)
     command: ["--apply-migrations"]
     environment:
       SERVERPOD_DATABASE_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in deploy/.env}

deploy/redeploy.sh

@@ -9,8 +9,8 @@
 #   - as a fast-forward of the deployed commit,
 #   - if every new commit is signed by a key in deploy/allowed-signers, as the deployed
 #     checkout lists them (so no commit can add its own key),
-# dumps the database first (the last 10 dumps stay in ~/backups), and fails unless the
-# server answers afterwards. A failure leaves the checkout at the deployed commit, so
+# dumps the database first (the last 10 dumps stay in ~/backups), applies the migrations
+# before switching to the new server, and fails unless that server answers afterwards. A failure leaves the checkout at the deployed commit, so
 # running the CI job again retries. By hand, with your own key:
 #
 #   ssh sahaquiel-deploy halkyon-learn/deploy/redeploy.sh <commit>
@@ -57,9 +57,15 @@ main() {
   git merge -q --ff-only "$commit"
   trap 'git reset -q --hard "$deployed"; echo "The checkout is back at $deployed." >&2' EXIT
   cd deploy
-  # Build while the running server keeps serving; then dump, then switch.
+  # Build while the running server keeps serving; then dump, migrate, switch.
   docker compose build -q server
   dump
+  # Migrations as a run of their own, before the switch: Serverpod's maintenance role
+  # applies them and exits with 0 only if that worked. Each migration is one
+  # transaction, so a failing one stops the deploy here and the running server keeps
+  # serving the schema it knows. (Until the switch, the old server serves the new
+  # schema; migrations that only add, as they should, keep that harmless.)
+  docker compose run --rm --no-deps -e role=maintenance server --apply-migrations
   docker compose up -d --remove-orphans
   wait_until_answering
   trap - EXIT