From c6b4831fc61fb0d5edeb051f1f545c8939716121 Mon Sep 17 00:00:00 2001 From: Anthony Ettinger Date: Thu, 24 Sep 2026 20:14:37 +0000 Subject: [PATCH] ops: chown .deploy-state to the deploy user too Running deploy-app.sh once as root during the initial migration leaves a root-owned .deploy-state. Every later CI deploy then builds, restarts and passes its health check, and fails on the very last line writing that file - so the deploy is reported failed while the site is actually running the new code, which is the worst possible way for this to break. Co-Authored-By: Claude Opus 5 (1M context) --- ops/selfhost/server/setup-app-host.sh | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ops/selfhost/server/setup-app-host.sh b/ops/selfhost/server/setup-app-host.sh index 408115e..beb369b 100755 --- a/ops/selfhost/server/setup-app-host.sh +++ b/ops/selfhost/server/setup-app-host.sh @@ -15,7 +15,11 @@ log() { printf '\n===> %s\n' "$*"; } log "App files to $USER_NAME, supabase/ to root" install -d -o "$USER_NAME" -g "$USER_NAME" -m 2750 "$ROOT" -for f in app.env deploy.env docker-compose.app.yml deploy-app.sh; do +# .deploy-state is included deliberately: running deploy-app.sh once as root +# (which is the natural thing to do during the initial migration) leaves a +# root-owned state file, and every later CI deploy then succeeds all the way +# through the health check and fails on the very last line writing it. +for f in app.env deploy.env docker-compose.app.yml deploy-app.sh .deploy-state; do [ -e "$ROOT/$f" ] && chown "$USER_NAME:$USER_NAME" "$ROOT/$f" done [ -e "$ROOT/app.env" ] && chmod 600 "$ROOT/app.env"