Deploy and upgrade only from tagged releases, not branch tip

deploy/upgrade.sh now fetches tags and checks out whichever sorts
newest (detached HEAD) instead of git pull --ff-only on a branch, now
that the project has a real release process (dated tags, e.g.
v2026.9.3) and a public mirror. Keeps production from ever landing on
an untagged commit. DEPLOYMENT.md's initial-clone steps and Upgrades
section updated to match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-04 21:31:08 -06:00
co-authored by Claude Sonnet 5
parent d74527a29c
commit 7a84d2f09f
2 changed files with 28 additions and 9 deletions
+17 -7
View File
@@ -159,9 +159,16 @@ anyone else under normal file permissions. `deploy/upgrade.sh`'s later
setup needed. Fine as long as the token is scoped to read-only access on setup needed. Fine as long as the token is scoped to read-only access on
just this repo. just this repo.
Either way, now that the repo is cloned: Either way, now that the repo is cloned, check out the latest release tag
rather than deploying whatever the default branch's tip happens to be —
`deploy/upgrade.sh` follows the same rule on every later upgrade (see §6),
so this keeps the very first deploy consistent with all the ones after it:
```bash ```bash
cd /srv/ds-chat
sudo -u ds-chat git fetch --tags
LATEST_TAG="$(sudo -u ds-chat git tag --sort=-creatordate | head -n1)"
sudo -u ds-chat git checkout --detach "$LATEST_TAG"
sudo -u ds-chat mkdir -p /srv/ds-chat/uploads sudo -u ds-chat mkdir -p /srv/ds-chat/uploads
``` ```
@@ -330,12 +337,15 @@ This is config in NPM's own UI/database, not a file this repo ships:
sudo -u ds-chat /srv/ds-chat/deploy/upgrade.sh sudo -u ds-chat /srv/ds-chat/deploy/upgrade.sh
``` ```
Pulls latest `main`, reinstalls backend deps, runs `alembic upgrade head`, Fetches tags and checks out whichever one sorts newest (`git tag
rebuilds the frontend, restarts `ds-chat`, and curls `/api/health` to --sort=-creatordate`) — deliberately not the default branch's tip, so
confirm it came back up. Fails loudly (`set -euo pipefail`) and stops running this between releases is a safe no-op rather than pulling in
before restarting anything if an earlier step — most importantly a failed whatever's mid-flight on `main`. Then reinstalls backend deps, runs
migration — errors out, so a bad deploy doesn't take down the previously `alembic upgrade head`, rebuilds the frontend, restarts `ds-chat`, and
working one. curls `/api/health` to confirm it came back up. Fails loudly
(`set -euo pipefail`) and stops before restarting anything if an earlier
step — most importantly a failed migration — errors out, so a bad deploy
doesn't take down the previously working one.
Active users get disconnected for a few seconds during the restart and Active users get disconnected for a few seconds during the restart and
reconnect automatically (same reconnect logic as §4's NPM-timeout note) — reconnect automatically (same reconnect logic as §4's NPM-timeout note) —
+11 -2
View File
@@ -16,9 +16,18 @@ BACKEND_DIR="${REPO_DIR}/backend"
FRONTEND_DIR="${REPO_DIR}/frontend" FRONTEND_DIR="${REPO_DIR}/frontend"
ENV_FILE="/etc/ds-chat/env" ENV_FILE="/etc/ds-chat/env"
echo "==> Pulling latest code" echo "==> Fetching latest release"
cd "$REPO_DIR" cd "$REPO_DIR"
git pull --ff-only git fetch --tags --force
LATEST_TAG="$(git tag --sort=-creatordate | head -n1)"
if [[ -z "$LATEST_TAG" ]]; then
echo "No tags found -- nothing to deploy" >&2
exit 1
fi
echo "Deploying $LATEST_TAG"
# Detached HEAD, not a branch checkout -- this directory only ever runs a
# tagged release, never whatever the default branch's tip happens to be.
git checkout --quiet --detach "$LATEST_TAG"
echo "==> Installing backend dependencies" echo "==> Installing backend dependencies"
cd "$BACKEND_DIR" cd "$BACKEND_DIR"