matt/central
1
0
Fork 0
mirror of https://github.com/zvx-echo6/central.git synced 2026-08-26 17:31:39 +00:00
Code Issues Projects Releases Packages Wiki Activity
central/scripts
History
Ubuntu 05bb293f17 deploy.sh: fix central-migrate env (cd + EnvironmentFile) so pre-flight check works 
central-migrate invocations were run via bare `cen "$VENV/bin/central-migrate"`,
which does not set the working directory or source the EnvironmentFile that the
systemd unit provides.  This caused the pre-flight --check to fail during the
v0.14.6 deploy with `PermissionError: [Errno 13] Permission error: '.env'`
because central-migrate tried to read .env from the caller's cwd instead of
/opt/central, and the DB DSN was missing.

The daemons themselves are unaffected — they always get WorkingDirectory=
/opt/central and EnvironmentFile=/etc/central/central.env from systemd.  The
deploy script is the only place that invoked central-migrate outside that context.

Fix: add ENV_FILE=/etc/central/central.env to the config block and a
cen_migrate() helper that wraps every central-migrate call with:
  sudo -u central bash -c "cd /opt/central && set -a && . /etc/central/central.env && set +a && /opt/central/.venv/bin/central-migrate <args>"
Replace all four bare invocations (--check preflight, --dry-run, apply,
--check post-deploy) with cen_migrate.  Exit-code propagation is unchanged —
bash -c forwards the inner exit status, so set -e / the ERR trap still fires
on non-zero exits.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-28 20:30:50 +00:00
..
.gitkeep scaffold: initial repository structure 2026-05-15 19:16:24 +00:00
deploy.sh deploy.sh: fix central-migrate env (cd + EnvironmentFile) so pre-flight check works 2026-06-28 20:30:50 +00:00
README.md scripts/deploy.sh: one-command tag-based deploy with pre-flight backup + verify (#115) 2026-06-28 14:13:55 -06:00

README.md

scripts/

deploy.sh — tag-based deploy for central on CT 104

Codifies the manual deploy procedure for the central service running on Proxmox CT 104 (utility, Tailscale 100.64.0.12).

What it does

  1. Preflight — checks that /opt/central is a git repo, captures the currently-deployed ref for rollback messaging, reports unit status (warns but does not abort on inactive units), runs central-migrate --check to gate on migration drift, and takes a pre-deploy pg_dump backup.
  2. Deploy — fetches from origin, verifies the requested ref exists, checks it out as a detached HEAD, and runs uv sync to update the venv against the checked-out uv.lock.
  3. Confirm — shows a --dry-run migration preview and prompts for confirmation before applying any changes to the running system (skip with -y).
  4. Apply — runs central-migrate to apply pending SQL migrations, then restarts all three systemd units (central-supervisor, central-archive, central-gui).
  5. Verify — confirms all units are active, re-runs central-migrate --check for a clean post-deploy state, and polls http://localhost:8000/health (up to 5 retries, 2 s apart) for an HTTP 200.
  6. ERR trap — on any unexpected failure, prints a ROLLBACK block with the exact commands to re-checkout the previous ref, re-sync the venv, restart services, and (if needed) restore from the pre-deploy dump.

Usage

Run on CT 104 as a user with passwordless sudo (e.g. zvx):

/opt/central/scripts/deploy.sh <tag-or-ref> [-y|--yes]
  • <tag-or-ref> — any Git tag, branch, or commit SHA (tags are the standard deploy unit; e.g. v0.14.5).
  • -y / --yes — skip the interactive confirmation prompt (safe for automation once you have reviewed the dry-run output manually).

Pre-flight backup

Before applying any changes, the script takes a pg_dump -Fc of the central database and writes it to /var/backups/central/. The 10 newest dumps are retained; older ones are pruned automatically.

Migrations are forward-only. There are no down-scripts. The pg_dump is the only automated mechanism for rolling back the database. If you need to revert after migrations have run, restore from the dump printed in the SUCCESS (or ERR-trap) output.

One-time cutover steps

Some releases require manual cutover steps that cannot be automated (e.g. removing a deprecated EONET region key from config.adapters). These are intentionally out of scope for this script. See the vault runbook central-deploy-cutover.md for guidance on release-specific procedures.

Bootstrap caveat

This script is version-controlled inside the central repository. The very first deploy that introduces it must still be performed manually (the script ships in the repo it deploys and cannot deploy itself from scratch).