From 9846977d003a722bf3eb6a8c71b05848317ae814 Mon Sep 17 00:00:00 2001
From: Dennis Thiessen <dennis@thiessen.io>
Date: Mon, 7 Sep 2026 19:59:12 +0200
Subject: [PATCH] fix(ci): don't exit early inside the ssh heredoc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The previous commit's health check worked — "healthy after 4s" was printed —
but the step still failed with exit code 1. The bug was mine: I added an
"exit 0" in the middle of the remote script, which the original never had.

The script is piped to the remote shell's stdin. Exiting in the middle closes
the channel while ssh is still writing the remaining lines, and the resulting
broken pipe fails the step even though the check passed. The original always
ran to the end of the heredoc on success, which is why it never hit this.

Now the loop records the result in a flag and breaks, and the only non-zero
exit is the very last statement. Both paths simulated: success exits 0, the
failure path exits 1 after dumping status and journal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HAH7vVtn7qbcn1EVheecHQ
---
 .gitea/workflows/deploy.yml | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/.gitea/workflows/deploy.yml b/.gitea/workflows/deploy.yml
index 2dc654d..e5bc4f9 100644
--- a/.gitea/workflows/deploy.yml
+++ b/.gitea/workflows/deploy.yml
@@ -175,22 +175,31 @@ jobs:
             # Poll instead of guessing how long startup takes. The old fixed
             # "sleep 3" then single curl raced whenever startup ran long, and
             # failed the deploy with a bare "connection refused" on a service
-            # that came up healthy a second later. This exits as soon as the app
-            # answers, so a fast start costs nothing.
+            # that came up healthy a second later.
+            #
+            # Record the result and fall through rather than exiting early: this
+            # script is piped to the remote shell's stdin, so an "exit 0" in the
+            # middle can close the channel while ssh is still writing the rest,
+            # which surfaces as a broken pipe and fails the step even though the
+            # check passed. Only the very last statement may exit non-zero.
+            healthy=0
             for i in $(seq 1 60); do
               if curl -fsS http://127.0.0.1:8998/api/v1/health > /dev/null 2>&1; then
+                healthy=1
                 echo "✓ signalplatform deployed — healthy after ${i}s"
-                exit 0
+                break
               fi
               sleep 1
             done
 
-            # Still down after a minute: this is a real failure, so leave enough
-            # behind to diagnose it without a second deploy.
-            echo "✗ health check failed: no response on :8998 after 60s"
-            sudo systemctl status signalplatform.service --no-pager -l || true
-            journalctl -u signalplatform.service -n 80 --no-pager || true
-            exit 1
+            # Still down after a minute: a real failure, so leave enough behind
+            # to diagnose it without running a second deploy to go looking.
+            if [ "$healthy" -ne 1 ]; then
+              echo "✗ health check failed: no response on :8998 after 60s"
+              sudo systemctl status signalplatform.service --no-pager -l || true
+              journalctl -u signalplatform.service -n 80 --no-pager || true
+              exit 1
+            fi
           REMOTE_SCRIPT
 
       - name: Clean up SSH key