3 Commits

Include renames

Author	SHA1	Message	Date
Waters ChurchandClaude Opus 5	39c65cf9de	Make the website deploy report its own failures ... The deploy was the one pipeline with no failure notification. It either worked or you found out by noticing the site was stale — the same shape as the off-site backup before today. alert.js now takes CHECKLIST_ENV_FILE and CHECKLIST_NODE_MODULES, because the deploy job runs in a container that has the repo but no server/.env and no node_modules; both live on the NAS at the mounted deploy directory. What this still does not catch, and the reason it is written down in the workflow: a runner that wedges. Today the NAS runner claimed run 7, executed none of its six steps, and Gitea timed it out fifteen minutes later — every step was marked failed without one having run, so no in-job step could have reported it. The container said "Up 2 hours" throughout and admitted on restart that it had been holding the job. A stuck runner looks exactly like a slow one, and catching it needs something watching from outside the run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 16:11:22 -04:00
Waters ChurchandClaude Opus 5	1d40872127	Drop the duplicate docker.sock mount from the deploy job ... act_runner already mounts /var/run/docker.sock into every job container, so declaring it again in the workflow made the daemon refuse to create the container at all: "Duplicate mount point: /var/run/docker.sock". The deploy directory still has to be declared, and still at its own host path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 14:02:51 -04:00
Waters ChurchandClaude Opus 5	00c2ad15a7	Deploy the web app from a push to main ... Until now a server change reached the NAS only when someone ran ./release.sh --web from a machine on the church network. That made the deploy depend on which laptop was awake and where it was, which is the same fragility that let the nightly Drive backup go stale unnoticed. An act_runner now runs in Docker on the NAS itself and picks up this workflow, so a push to main rebuilds the container regardless of where the push came from. The workflow keeps the protections the old remote deploy script had, because they are the ones that matter: server/data and server/.env are excluded from the copy and then explicitly checked for afterwards, and the container is recreated with 'up -d --build' rather than 'down' first, so an interrupted deploy leaves the old container serving instead of tearing the stack down. rsync runs without --delete, matching the tarball deploy it replaces — a stale file is survivable, a wiped data/ is not. This covers the web app only. The iOS and Android apps bundle a copy of the UI at build time, so they still need ./release.sh and a store release; server-side changes reach them immediately, since they call this same server live. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 13:57:31 -04:00