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
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
Widens the lint step from `ruff check app/` to `ruff check .`, since tests/ and
scripts/ had drifted to 11 findings while unchecked (fixed in 1c6ccce).
Widening alone would have been unsafe, and the check turned up something worse
than the drift: CI installs ruff unpinned, the repo had no [tool.ruff] config,
and ruff's default rule set is not stable across releases. Local 0.15.4 reports
0 findings in app/; 0.16.2 -- what `pip install ruff` resolves to today --
reports 376. 168 of those are B008 flagging FastAPI's `Depends()` in a signature
default, which is the framework's documented idiom, not a defect. So the lint
job would have failed the deploy pipeline on untouched code at the next push,
independent of this change.
Pinning the ruff version would freeze the bug in place. Pinning the *rule set*
is the actual fix: select = ["E4", "E7", "E9", "F"] in pyproject.toml, the set
the tree was already clean under, now enforced repo-wide. The ruff version can
float freely without changing what CI enforces.
Verified both scopes against both versions with caches disabled: `ruff check .`
passes under 0.15.4 and 0.16.2. Confirmed the pin actually binds rather than
passing by luck -- a probe file using `Depends()` in a default is clean under
the committed config and reports B008 + I001 under `--isolated` 0.16.2 defaults.
Full suite still 852 passed, 1 skipped.
Adding rules is welcome; do it in pyproject.toml with the fixes in the same
commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- admin_service: register benchmark_collector in VALID_JOB_NAMES, JOB_LABELS and
PIPELINE_MEMBERS. The Admin → Jobs list is built from these hardcoded sets, not
the scheduler, so the job was registered but invisible/untriggerable.
- deploy.yml:
- SSH: verify the host key (StrictHostKeyChecking=yes) now that known_hosts is
supplied; move private-key cleanup to an `if: always()` step.
- Add a concurrency guard so deploys serialize.
- Health-check the service after restart (127.0.0.1:8998/api/v1/health).
- Align CI Python to 3.12 (matches prod); pip + npm caching.
- Clarify the Postgres service only validates migrations (tests use SQLite);
drop the redundant DATABASE_URL from the pytest step.
- Split the monolithic "Deploy to server" step into named steps.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dennisthiessenandClaude Opus 5