fix(manage-server): upgrade.sh breaks on podman-compose (no rm subcommand) #19

Merged

amiryahaya merged 1 commit from fix/upgrade-sh-podman-compose-rm into main

2026-08-17 04:36:40 +02:00

amiryahaya commented

2026-08-16 19:11:23 +02:00

Owner

Summary

Sync of amiryahaya/triton PR #756 (source of truth: scripts/deploy/manage-server/upgrade.sh).

upgrade.sh called ${COMPOSE[@]} rm -f manage-server, but podman-compose 1.0.6 has no rm subcommand at all — the upgrade aborted under set -e right after stopping the old container, leaving the manage server down and never recreated. Reproduced live: fresh install.sh at rc.12, upgrade.sh --image ...:1.1.0-rc.13 stopped the app and died there.
Fixed by calling the runtime (podman/docker) directly for stop/rm instead of going through compose.
Also found (same repro): podman-compose 1.0.6 computes its recreate decision from a whole-project config hash, not per-service, so --no-deps doesn't reliably stop it from also recreating triton-manage-db whenever .env changed. Not destructive (same named volume/env, clean restart) but the script's comment asserted this never happens. Added a guard that detects it and waits for postgres to come back up before continuing, and corrected the comment.
Bumped SCRIPT_VERSION.
Preserved this repo's existing TRITON_MANAGE_JWT_SIGNING_KEY backfill block (#18) — separate, pre-existing drift not yet ported back to the source-of-truth repo, flagged to the maintainer, out of scope for this PR.

Test plan

Verified end-to-end on a live podman-compose host: reproduced the unpatched crash, deployed the patched script, ran rc.12 -> rc.13 upgrade to completion (upgrade complete, container on rc.13, /api/v1/health OK).
bash -n syntax check.

🤖 Generated with Claude Code

## Summary Sync of amiryahaya/triton PR #756 (source of truth: `scripts/deploy/manage-server/upgrade.sh`). - `upgrade.sh` called `${COMPOSE[@]} rm -f manage-server`, but podman-compose 1.0.6 has no `rm` subcommand at all — the upgrade aborted under `set -e` right after stopping the old container, leaving the manage server **down and never recreated**. Reproduced live: fresh `install.sh` at rc.12, `upgrade.sh --image ...:1.1.0-rc.13` stopped the app and died there. - Fixed by calling the runtime (`podman`/`docker`) directly for stop/rm instead of going through compose. - Also found (same repro): podman-compose 1.0.6 computes its recreate decision from a whole-project config hash, not per-service, so `--no-deps` doesn't reliably stop it from also recreating `triton-manage-db` whenever `.env` changed. Not destructive (same named volume/env, clean restart) but the script's comment asserted this never happens. Added a guard that detects it and waits for postgres to come back up before continuing, and corrected the comment. - Bumped `SCRIPT_VERSION`. - Preserved this repo's existing `TRITON_MANAGE_JWT_SIGNING_KEY` backfill block (#18) — separate, pre-existing drift not yet ported back to the source-of-truth repo, flagged to the maintainer, out of scope for this PR. ## Test plan - [x] Verified end-to-end on a live podman-compose host: reproduced the unpatched crash, deployed the patched script, ran rc.12 -> rc.13 upgrade to completion (`upgrade complete`, container on rc.13, `/api/v1/health` OK). - [x] `bash -n` syntax check. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

amiryahaya added 1 commit

2026-08-16 19:11:23 +02:00

fix(manage-server): upgrade.sh breaks on podman-compose (no rm subcommand) e8a7fb4b1f

podman-compose 1.0.6 has no `rm` subcommand, so `${COMPOSE[@]} rm -f
manage-server` aborted the upgrade under set -e right after stopping the
old container, leaving the manage server down and never recreated.
Verified live: install.sh at rc.12, upgrade.sh --image rc.13 stopped the
app and died there.

Switch the stop/rm step to call the runtime directly instead of going
through compose. Also detected that podman-compose computes its recreate
decision from a whole-project config hash rather than a per-service one,
so `--no-deps` doesn't reliably keep it from also recreating
triton-manage-db whenever .env changed — not destructive (same named
volume/env), but the script asserted it never happened. Added a guard
that detects this and waits for postgres to come back up instead of
silently trusting it, and corrected the comment.

Re-verified end-to-end: rc.12 -> rc.13 upgrade now completes cleanly via
upgrade.sh with no manual intervention.

Source of truth: scripts/deploy/manage-server/upgrade.sh in
amiryahaya/triton, PR #756.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

amiryahaya merged commit 9d10fecc21 into main

2026-08-17 04:36:39 +02:00

amiryahaya referenced this pull request from a commit

2026-08-17 04:36:40 +02:00

Merge pull request 'fix(manage-server): upgrade.sh breaks on podman-compose (no rm subcommand)' (#19) from fix/upgrade-sh-podman-compose-rm into main