ci(deploy): tolerate 403 on post-deploy health check (#8)
The peptide-starter-theme v1.5.2 release added peptide_starter_is_cloudflare_peer() — a CF-peer IP validator that correctly rejects direct-to-origin requests as non-Cloudflare traffic with HTTP 403. The deploy workflow's post-deploy health check makes exactly such a request from a GHA runner IP, so it now reliably receives 403 even on successful deploys. Two deploys today (peptide-starter-theme v1.5.2, prautoblogger Commit 1a) both succeeded but reported workflow failure due to this. The actual deploys (rsync + cache purge) ran clean; site verified HTTP 200 from real traffic both times. Fix: accept either 200 (normal healthy response) or 403 (validator actively rejecting non-CF origin — itself a positive liveness signal) in the health check. Reject only on 5xx, 4xx-other, or connection failure. Reverting this fix is correct only if we either (a) bypass the validator for our own health-check user-agent, or (b) route the health check through Cloudflare. Both are larger changes for a later release. Agent-Session: cowork-deploy-healthcheck-fix-20260415 Co-authored-by: peptiderepo <peptiderepo@users.noreply.github.com>
This commit is contained in:
19
.github/workflows/deploy.yml
vendored
19
.github/workflows/deploy.yml
vendored
@@ -248,20 +248,25 @@ jobs:
|
||||
run: |
|
||||
echo "Verifying site is accessible after deploy..."
|
||||
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 30 "https://peptiderepo.com/")
|
||||
if [ "$HTTP_STATUS" -eq 200 ]; then
|
||||
echo "✓ Site returned HTTP $HTTP_STATUS"
|
||||
# Accept 200 (healthy) or 403 (peptide-starter-theme v1.5.2 CF-peer
|
||||
# validator rejecting this GHA-runner direct-to-origin request as
|
||||
# non-Cloudflare traffic — that rejection is the validator working).
|
||||
# Real user traffic via Cloudflare gets 200.
|
||||
if [ "$HTTP_STATUS" -eq 200 ] || [ "$HTTP_STATUS" -eq 403 ]; then
|
||||
echo "✓ Site responsive (HTTP $HTTP_STATUS)"
|
||||
else
|
||||
echo "⚠ Site returned HTTP $HTTP_STATUS (expected 200)"
|
||||
echo "⚠ Site returned unexpected HTTP $HTTP_STATUS"
|
||||
echo "The deploy completed but the site may need attention."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Verify REST API endpoint is responding.
|
||||
# Verify REST API endpoint is responding. Same 200/403 tolerance:
|
||||
# the REST endpoint is also gated by the CF-peer validator.
|
||||
REST_STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 15 "https://peptiderepo.com/wp-json/peptides/v1/search?q=BPC-157")
|
||||
if [ "$REST_STATUS" -eq 200 ]; then
|
||||
echo "✓ REST API returned HTTP $REST_STATUS"
|
||||
if [ "$REST_STATUS" -eq 200 ] || [ "$REST_STATUS" -eq 403 ]; then
|
||||
echo "✓ REST API responsive (HTTP $REST_STATUS)"
|
||||
else
|
||||
echo "⚠ REST API returned HTTP $REST_STATUS (expected 200)"
|
||||
echo "⚠ REST API returned unexpected HTTP $REST_STATUS"
|
||||
fi
|
||||
|
||||
- name: Deploy summary
|
||||
|
||||
Reference in New Issue
Block a user