4 Commits

Include renames

Author	SHA1	Message	Date
jaredandClaude Opus 5	b6ea4a333e	fix(cinny-deploy): queue a trigger that arrives mid-deploy instead of dropping it ... lotus_deploy.sh took an flock and exited if a deploy was already running. The poll loop only retargets origin/lotus while it is still waiting on CI; a push that lands during npm ci / npm run build was silently never deployed until the next unrelated push (cinny 81a6d9c9 — the MSC4515 call fix — passed CI but never reached the web root). A concurrent trigger now leaves a .pending marker and the running deploy re-execs itself once at the end, which re-fetches and re-gates on CI as usual. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA	2026-09-14 19:25:28 -04:00
jaredandClaude Opus 4.8	c15a48971d	deploy(cinny): follow origin/lotus HEAD while gating on CI ... Companion to cinny's `concurrency: cancel-in-progress`. The poll loop latched origin/lotus once at startup; with CI cancel-in-progress a superseded run's status flips to error/failure, so polling the latched (now-cancelled) SHA would abort and — with the flock skipping the newer push's deploy — strand the newest commit undeployed (a deploy freeze, the exact class this script fought before). - Re-resolve origin/lotus each poll iteration; retarget the CI gate to HEAD if it advanced (fresh MAX_WAIT window). - On a failure/error status, re-check HEAD before aborting — only a genuine failure of the CURRENT HEAD aborts; a superseded/blip SHA is followed instead. - Reset to the gated $COMMIT_SHA (not a bare origin/lotus that may have advanced past the gate after the loop) so we build exactly what passed CI. shellcheck clean; reviewed (SHIP). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 22:09:30 -04:00
jaredandClaude Fable 5	d344b9b4b5	fix(ci): make the SC1091 suppression in lotus_deploy.sh actually apply ... Shellcheck directives bind to the NEXT command; on the compound line `set -a; source /etc/lotus-deploy.env; set +a` the existing `# shellcheck disable=SC1091` bound to `set -a`, so the info-level SC1091 finding on the runtime-only env file still failed the lint workflow (find -exec shellcheck exits non-zero on any finding). Split the line so the directive sits directly above `source` (as `source=/dev/null`, the standard idiom for host-only env files). Verified with CI's exact invocation: `find . -name "*.sh" -exec shellcheck {} +` now exits 0 (shellcheck 0.9.0). No runtime behavior change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-01 22:19:39 -04:00
jaredandClaude Opus 4.8	c13549f3da	cinny: harden + version-control the webhook web-deploy (lotus_deploy.sh) ... The live /usr/local/bin/lotus_deploy.sh (the `lotus-deploy` webhook target) was never under version control and had rotted into two deploy-killing bugs that froze chat.lotusguild.org on an old build: 1. CI gate: it waited on the WHOLE workflow run with a 15-min cap. Web CI shares the single act_runner with the slow Tauri desktop builds, so a web run could sit queued >15 min -> "result: timeout" -> deploy aborted. Now it gates only on the "Build & Quality Checks" commit-status context (build + unit tests), decoupled from "Trigger Desktop Build", and waits up to 45 min. 2. Dead element-call copy: `cp node_modules/@element-hq/element-call-embedded/...` under `set -e` aborted every deploy after the widget was forked to @lotusguild/element-call-embedded. The build already emits dist/public/ element-call; replaced the copy with a presence check. Also: rsync now excludes config.json so the app deploy stops clobbering the production runtime config (homeserver list / allowCustomHomeservers) that the matrix repo owns. lxc106-cinny.sh now installs this script (syntax-checked). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 18:10:10 -04:00