From 09119e775f10e6e29959e5e2090893829f512f22 Mon Sep 17 00:00:00 2001
From: Thomas Faour <tom@tfao.ca>
Date: Sat, 1 Aug 2026 12:46:05 +0000
Subject: [PATCH] Deploy: retry "docker compose up -d" instead of guessing at a
 stale container

The previous fix (kill anything on port 8420 before up) didn't help --
confirmed nothing was actually squatting on the port. The real cause,
per the maintainer: "up -d" run manually a few seconds after "down"
always succeeds, but scripted straight through (down && pull && up,
pull sometimes a no-op if the image is already cached) fails every
time. That's "down" returning before the OS/docker-proxy has actually
released port 8420 yet, not an orphaned container -- a timing race, not
a stuck process. Retrying "up -d" a few times with a short pause rides
out that race without needing to guess a fixed sleep long enough to
always cover it.
---
 .gitea/workflows/server-docker-build.yml | 29 ++++++++++++++++++------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/.gitea/workflows/server-docker-build.yml b/.gitea/workflows/server-docker-build.yml
index 96b1d0c..df8174d 100644
--- a/.gitea/workflows/server-docker-build.yml
+++ b/.gitea/workflows/server-docker-build.yml
@@ -68,10 +68,25 @@ jobs:
           chmod 600 ~/.ssh/deploy_key
           ssh-keyscan -p "$DEPLOY_PORT" "$DEPLOY_HOST" >> ~/.ssh/known_hosts 2>/dev/null
           ssh -i ~/.ssh/deploy_key -p "$DEPLOY_PORT" -o StrictHostKeyChecking=yes \
-            espressoframe_deployer@"$DEPLOY_HOST" \
-            'cd ~/espresso-frame && \
-             docker compose down --remove-orphans && \
-             docker ps -q --filter publish=8420 | xargs -r docker stop && \
-             docker ps -aq --filter publish=8420 | xargs -r docker rm && \
-             docker compose pull && \
-             docker compose up -d'
+            espressoframe_deployer@"$DEPLOY_HOST" bash -s <<'REMOTE'
+          set -e
+          cd ~/espresso-frame
+          docker compose down --remove-orphans
+          docker compose pull
+          # "down" returning doesn't guarantee the OS/docker-proxy has
+          # actually released port 8420 yet -- an immediate "up -d" right
+          # after (especially with "pull" a no-op because the image was
+          # already cached) can lose that race and fail with "port is
+          # already allocated", even though the exact same "up -d" run a
+          # few seconds later succeeds every time. Retry instead of
+          # guessing at a fixed sleep long enough to always cover it.
+          for i in $(seq 1 10); do
+            if docker compose up -d; then
+              exit 0
+            fi
+            echo "docker compose up -d failed (attempt $i/10) -- retrying in 3s"
+            sleep 3
+          done
+          echo "docker compose up -d did not succeed after 10 attempts"
+          exit 1
+          REMOTE