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	ff6785b800	Send backup alerts to a person, not just the shared inbox ... Failures went to REPORT_EMAIL, which is the media@ shared inbox the Sunday digest already uses. An alert competing with a routine weekly mail in a shared inbox is an alert that gets scrolled past, which is most of the way back to the logfile nobody read. ALERT_EMAIL is now a separate, comma-separated list for breakage only, falling back to REPORT_EMAIL so a machine whose .env predates this still alerts somewhere rather than silently not at all. Verified by sending one test alert, which arrived. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 14:18:47 -04:00
Waters ChurchandClaude Opus 5	3d82e46951	Make the off-site backup find Drive, and say so when it cannot ... The nightly copy to Drive had been dead since 15 September. DRIVE_DIR pointed at Apps/Backups/Checklist Backups; the folder is Apps/Checklist Backups, with no Backups level. The guard for a missing folder did its job and exited — into a logfile nobody reads, so from the outside a broken backup and a healthy no-op looked identical. Eight days were missing; this run copied them. That is the second time the same failure has hidden in the same place. The header comment already records the first: ten weeks stale in July, found in September. Correcting the path alone would leave the mechanism that hid it untouched, so: - The Drive folder is probed rather than hard-coded, across every mounted GoogleDrive-* account and both known folder layouts. The laptop mounts christian@ where the Studio mounts media@, and the folder has moved once already, so a literal path is the wrong thing to depend on. - Every failure now emails as well as logs, via scripts/alert.js, which reuses the server's own SMTP settings. A failed alert never masks the failure it was reporting. - A run that does not error but leaves the newest off-site copy more than STALE_DAYS old now alerts too. That is the check that would have caught both incidents; the error paths only fire when the script actually runs. What this still cannot catch is the script never running at all — a sleeping Mac or an unloaded LaunchAgent is silent by construction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-24 14:16:50 -04:00