Swaping back to nodejs dependent checkout

README.md

@@ -97,52 +97,54 @@ Edit `User=` and the paths in it if you keep the panel somewhere else.
 
 ## Deploying from Gitea
 
-`.gitea/workflows/deploy.yml` fast-forwards the checkout on the server,
-installs anything new from `requirements.txt`, runs the tests, restarts the
-service and waits for the panel to answer again.
+`.gitea/workflows/deploy.yml` checks out the push, runs the tests, rsyncs
+the tree into place, installs anything new from `requirements.txt`,
+restarts the service and waits for the panel to answer again. The tests run
+before the rsync, so a failure leaves the server exactly as it was.
 
-### Once, by hand on the server
+### The runner
 
-The workflow only ever *updates* a checkout. It never creates one, so the
-remote and whatever credentials reach it are set up a single time and stay
-put. As the user the runner runs as:
+Host mode, on the machine that serves the panel, registered with the label
+`heos` (`runs-on:` must match, or the job queues forever), running as a user
+that can write to the deploy path. It also needs **node 20 or newer** on its
+PATH: `actions/checkout` is a JavaScript action, and a host-mode runner has
+nothing else to run one with — without it the job fails immediately with
+`Cannot find: node in PATH`.
+
+### Once, on the server
+
+The deploy path does not need to be a checkout — an empty directory the
+runner can write to is enough:
 
 ```bash
-git clone <this repo> /var/www/html/heos
-cd /var/www/html/heos
-python3 -m venv .venv
-.venv/bin/pip install -r requirements.txt
-
-sudo cp deploy/heos-panel.service /etc/systemd/system/
-sudo systemctl daemon-reload
-sudo systemctl enable --now heos-panel
+sudo mkdir -p /var/www/html/heos
+sudo chown "$(id -un)": /var/www/html/heos
 
 echo "$(id -un) ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart heos-panel" \
   | sudo tee /etc/sudoers.d/heos-panel
 sudo chmod 440 /etc/sudoers.d/heos-panel
 ```
 
-Edit `User=` and the paths in the unit if the panel lives somewhere else or
-runs as someone else. Until that clone exists the workflow stops on its
-first real step and prints these commands back at you.
+Then push. That first run deploys the files and builds the virtualenv, and
+stops at the restart, because the service does not exist yet. Install it
+from the copy it just put there:
 
-### The runner
+```bash
+sudo cp /var/www/html/heos/deploy/heos-panel.service /etc/systemd/system/
+sudo systemctl daemon-reload
+sudo systemctl enable heos-panel
+```
 
-Host mode, on the machine that serves the panel, registered with the label
-`heos` (`runs-on:` must match, or the job queues forever), running as the
-user that owns the checkout — it writes there, and it fetches with that
-checkout's own git credentials.
+Edit `User=` and the paths in the unit first if the panel lives somewhere
+else or runs as someone else. Re-run the workflow and it goes green.
 
-Every step is plain shell. `actions/checkout` is a JavaScript action, and a
-host-mode runner can only run those with `node` on its PATH; without one it
-fails with `Cannot find: node in PATH`.
+### What survives a deploy
 
-Nothing untracked is disturbed, so `.venv` and `members.json` — the runtime
-and the stereo pair's learned membership — survive a deploy untouched. The
-fast-forward is `--ff-only`, so a tracked file edited on the box without
-being committed stops the deploy rather than being silently overwritten.
-`config.py` is tracked: your device names live in git, so change them there
-and push, rather than editing the deployed copy.
+The rsync excludes `.venv` and `members.json`, so the runtime and the stereo
+pair's learned membership are left alone by `--delete`. Everything else in
+the deploy path is made to match the repo, `config.py` included: your device
+names live in git, so change them there and push rather than editing the
+deployed copy.
 
 ## Behind a reverse proxy, at /heos