4 Commits

Include renames

Author	SHA1	Message	Date
Waters ChurchandClaude Opus 5	af97626b12	Fix the build workflow's YAML so it actually runs ... The alert steps passed their message body as a bare multi-line argument starting at column 0. That ends the YAML block scalar, which makes the whole file invalid: "a multiline key may not be an implicit key". Gitea still listed the workflow as active and simply never created a run for it — no error anywhere, which is why two pushes appeared to do nothing. The bodies are built with indented heredocs now, so every line stays inside the block scalar. Validated by parsing the file rather than by eye; a workflow that is registered but silently never triggers looks exactly like one that works. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 15:39:08 -04:00
Waters ChurchandClaude Opus 5	76e74dc0fa	Rebuild both apps automatically when something they bundle changes ... The web app has deployed on push since earlier today, but the phone apps carry their own frozen copy of the UI, so a change to server/public silently left them behind until someone remembered to cut a release. Remembering was the weak part. A second Actions runner now runs on the ingest Mac — in host mode, because an app build needs Xcode, the Android SDK and the signing keys, none of which exist in the NAS runner's Linux container. A push touching server/public, mobile/src or the Capacitor config rebuilds and signs both apps, then emails to say the shipped apps are behind, or that the build broke. It deliberately stops before uploading. An upload needs a build number that has never been used, Play refuses to reuse or lower a versionCode, and bumping it means committing the new number back from the build machine on every run. That needs write access from that machine and permanently changes the numbering scheme — a one-way door, so shipping stays an explicit ./release.sh. release.config.json is excluded from the trigger paths so that bumping a build number by hand cannot set off a rebuild of what was just built. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 15:32:18 -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