Skip to content

upgrade.md

Latest commit

 

History

History
101 lines (73 loc) · 3.03 KB

upgrade.md

File metadata and controls

101 lines (73 loc) · 3.03 KB
Raw

Upgrading & Deploying

Full pipeline reference: Deploy Pipeline.

Telegram commands (master role only)

Command What it does
/update dev | alpha | stable Pull/build from channel, deploy, restart
/update abmind Update the memory system separately
/software Show versions, source, rollback slots
/software rollback <slot> Roll back to slot 1-3

Remote deploy is one step: /update dev (or alpha / stable). pull, deploy, build, and git are legacy aliases for /update dev.

Linux / WSL

abtars update --alpha

--stable tracks stable releases, --dev tracks dev (add a directory, --dev <dir>, to deploy from a local checkout). The update builds from source, stages the release, atomically repoints releases/current, restarts, and health-verifies. An unhealthy result requires operator review; the update health check does not directly roll back the release. A separate boot circuit breaker can restore a previous release after repeated unplanned bridge deaths.

macOS

From Telegram (remote):

/update dev          ← pull latest dev, build, deploy, restart (one step)
/update alpha        ← same from the npm alpha channel

abmind-only changes

abtars never bundles abmind — it is discovered at runtime from the global install. Update it independently; rebuilding/redeploying abtars is not the abmind update mechanism:

abmind update --dev

Or from the bridge (master role): /update abmind.

Verify after deploy

abtars status

Or via Telegram: /status, /software

Shows: version, commit, bridge PID + health, source (npm or local + repo path). Also check:

  1. ✓ Bridge healthy in update output
  2. Telegram polling started (check logs)
  3. No EADDRINUSE errors

Rollback

abtars rollback            # previous release (slot 1)
abtars rollback --to 2     # slot 2 (slots 1-3, from history.json)

Or via Telegram: /software rollback 2. Repoints releases/current, updates the manifest, and respawns the bridge from the target release.

If deploy fails

If the bridge stays unhealthy after an update:

  1. Check logs: ls ~/.abtars/logs/ and tail the latest bridge log
  2. Check status: abtars status, abtars doctor --fix
  3. Roll back: abtars rollback
  4. If the CLI itself is broken, use the emergency script below

If abtars update itself is broken

When the deployed CLI is so broken that abtars update cannot run — for example the wrapper can't locate the bundle, or the bridge is dead and the watchdog can't respawn it — use the emergency script. It builds the source checkout, stages releases/<commit>/, repoints the current + app links, restarts the watchdog, and runs a liveness check with plain npm + node and direct launchctl/systemd calls. No working deployed binary required.

bash ~/.abtars-releases/src/abtars/scripts/emergency-update.sh

Make sure the source checkout is on the commit you want first:

cd ~/.abtars-releases/src/abtars && git pull