fix(ci): poll the health endpoint instead of sleeping a fixed 3s
Deploy / lint (push) Successful in 12s
Deploy / test (push) Successful in 2m12s
Deploy / deploy (push) Failing after 55s

The deploy failed with "curl: (7) Failed to connect to 127.0.0.1 port 8998
after 0 ms" on a service that was in fact running. "after 0 ms" is
connection-refused, not a timeout: the check fired before uvicorn had bound the
port. A fixed "sleep 3" followed by a single curl has no retry, so it fails the
whole deploy whenever startup runs a second long.

Raising the sleep would slow every deploy and still race on a bad day. This
polls once a second for up to 60s and exits as soon as the app answers, so a
fast start costs nothing and a slow one no longer fails.

On a genuine failure it now dumps systemctl status and the last 80 journal
lines, so the cause is visible without running a second deploy to go looking.

The heredoc is quoted so the loop's $i and $(seq) expand on the remote host
rather than in the runner's shell; that block has no local variables or
${{ }} expressions, so quoting is safe here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HAH7vVtn7qbcn1EVheecHQ
This commit is contained in:
dennisthiessenandClaude Opus 5 committed 2026-09-07 19:53:12 +02:00
1 parent 25e821435d
commit 6ac4b31dfa
1 file changed
+23 -5
+23 -5
View File
@@ -166,13 +166,31 @@ jobs:
- name: Restart service & health check
run: |
ssh $SSH_OPTS "${DEPLOY_USER}@${DEPLOY_HOST}" << REMOTE_SCRIPT
# Quoted heredoc: the loop's $i / $(seq) must be expanded on the
# REMOTE host, not by this runner's shell before it is sent.
ssh $SSH_OPTS "${DEPLOY_USER}@${DEPLOY_HOST}" << 'REMOTE_SCRIPT'
set -e
sudo systemctl restart signalplatform.service
sleep 3
curl -fsS http://127.0.0.1:8998/api/v1/health > /dev/null \
|| { echo "✗ health check failed after restart"; exit 1; }
echo "✓ signalplatform deployed"
# 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.
for i in $(seq 1 60); do
if curl -fsS http://127.0.0.1:8998/api/v1/health > /dev/null 2>&1; then
echo "✓ signalplatform deployed — healthy after ${i}s"
exit 0
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
REMOTE_SCRIPT
- name: Clean up SSH key