From 0c41d9f70b7135d425df162246851c90710ab80c Mon Sep 17 00:00:00 2001 From: Twooey Date: Thu, 27 Aug 2026 11:46:49 -0400 Subject: [PATCH] Fix wordpress-readiness race in deploy.sh MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The bring-up wait only checked that php-cli runs, not that the official image had finished copying WordPress's core files into the (possibly freshly-emptied) wp_core volume — a step that takes a few real seconds on first boot. On a fast pass through that window, wp-cli would run against an empty /var/www/html and fail with "This does not seem to be a WordPress installation," even though the container was otherwise healthy. Now waits on wp-settings.php actually existing instead. Co-Authored-By: Claude Sonnet 5 --- deploy/deploy.sh | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/deploy/deploy.sh b/deploy/deploy.sh index 4149917..5f10673 100755 --- a/deploy/deploy.sh +++ b/deploy/deploy.sh @@ -53,13 +53,13 @@ chmod 644 "$SECRETS_DIR/db_password" "$SECRETS_DIR/db_root_password" echo "==> building and starting ${ENVIRONMENT}" $COMPOSE up -d --build -echo "==> waiting for the wordpress container to come up" -for i in $(seq 1 30); do - if $COMPOSE exec -T wordpress php -v >/dev/null 2>&1; then +echo "==> waiting for WordPress core files (the official image copies them in on first boot of an empty volume, which takes a few seconds)" +for i in $(seq 1 60); do + if $COMPOSE exec -T wordpress test -f /var/www/html/wp-settings.php >/dev/null 2>&1; then break fi - if [[ "$i" -eq 30 ]]; then - echo "wordpress container did not become ready in time" >&2 + if [[ "$i" -eq 60 ]]; then + echo "wordpress core files did not appear in time" >&2 exit 1 fi sleep 2