Christian Manivong ec93619f8f fix: one deploy per host at a time, under a lock the host frees on its own ...

Several sessions deploy to the same test server, and two runs used to
overlap. On 2026-10-05 two `up -d --force-recreate` runs recreated each
other's containers and the API was down for a minute (#1). On 2026-10-06
two runs renamed each other's *.new compose files and one broke off; with
two different tags, one tag's compose files could have started the
other's images (#3).

- Each deploy first takes flock on ~/netork/.deploy.lock on the host. An
  ssh session holds it: the remote side takes the lock on fd 9, reports
  LOCKED and waits on its stdin, so ending the session frees it, whether
  the deploy finished, failed, was interrupted or lost its connection.
  Checked over real ssh on .50, including a client killed with -9.
- A second deploy prints who holds the lock, since when and with which
  tag, and waits up to DEPLOY_LOCK_WAIT seconds (default 900); then it
  gives up without touching the host.
- A host without flock is deployed without the lock, with a warning.
- deploy_server is now the lock around deploy_steps, the old body.

Closes #1
Closes #3

2026-10-07 06:42:13 +02:00

..

test_deploy_host_lock.py

fix: one deploy per host at a time, under a lock the host frees on its own

2026-10-07 06:42:13 +02:00

test_deploy_recreate_retry.py

fix: one deploy per host at a time, under a lock the host frees on its own

2026-10-07 06:42:13 +02:00

test_deploy_script_bootstrap.py

Initial import of the netOrk deploy script

2026-09-28 19:55:22 +02:00

test_deploy_script_fails_loudly.py

Initial import of the netOrk deploy script

2026-09-28 19:55:22 +02:00