You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The post-deploy smoke step added in #111 fails on main, so every deploy run is now red even though the site is healthy.
What happened
The step probes four canonical URLs. From the GitHub Actions runner:
path
result
/
403 (10 retries, ~100s)
/feed.xml
403 (10 retries, ~100s)
/.well-known/security.txt
200
/.well-known/pgp-security.asc
200
The two paths the step exists to guard pass. The two canaries fail.
Cause
Cloudflare bot protection blocks the runner's datacenter IP on ordinary paths. /.well-known/ is exempt — Cloudflare allowlists that prefix from bot challenges by design, so ACME and security.txt keep working — which is why exactly the paths we care about got through and the canaries did not.
Not a site fault. Verified simultaneously:
Pages origin, all four paths: 200 (the artifact is complete)
https://material-identity.eu/ and /feed.xml from a residential IP: 200
The canaries were there to distinguish "site is down" from "well-known is missing". They cannot do that job from CI, and the retry loop turns each one into a ~100s stall before failing.
Fix
Split the probe by what each half can actually prove:
Canonical host, the /.well-known/ paths only: proves the Worker's rewrite and its content types. These demonstrably pass from CI, and they are the reachable subset.
Dropping / and /feed.xml from the canonical-host probe is not a weakening. Their purpose was to prove the site was up, and a 200 from /.well-known/security.txt on the same host already proves that. The origin half covers them for artifact completeness.
Also assert the content types on the canonical host, not just the status: text/plain; charset=utf-8 and application/pgp-keys are the actual requirement from #107/#109, and a 200 with the wrong type would still be a regression.
Note
The alternative — a Cloudflare WAF skip rule for GitHub's IP ranges — is a manual console change (Manual-Setup-Checklist.md territory) and widens the site's exposure to make a test convenient. Not worth it when the origin probe covers the same ground.
The post-deploy smoke step added in #111 fails on
main, so every deploy run is now red even though the site is healthy.What happened
The step probes four canonical URLs. From the GitHub Actions runner:
//feed.xml/.well-known/security.txt/.well-known/pgp-security.ascThe two paths the step exists to guard pass. The two canaries fail.
Cause
Cloudflare bot protection blocks the runner's datacenter IP on ordinary paths.
/.well-known/is exempt — Cloudflare allowlists that prefix from bot challenges by design, so ACME andsecurity.txtkeep working — which is why exactly the paths we care about got through and the canaries did not.Not a site fault. Verified simultaneously:
https://material-identity.eu/and/feed.xmlfrom a residential IP: 200The canaries were there to distinguish "site is down" from "well-known is missing". They cannot do that job from CI, and the retry loop turns each one into a ~100s stall before failing.
Fix
Split the probe by what each half can actually prove:
material-identity.github.io/dictionary), all paths includingwell-known/: proves the artifact contains what we built. This is precisely the /.well-known/ 404s in production: upload-pages-artifact strips dot-directories #110 regression class, generalized beyond the two files, and there is no bot protection in front of it./.well-known/paths only: proves the Worker's rewrite and its content types. These demonstrably pass from CI, and they are the reachable subset.Dropping
/and/feed.xmlfrom the canonical-host probe is not a weakening. Their purpose was to prove the site was up, and a 200 from/.well-known/security.txton the same host already proves that. The origin half covers them for artifact completeness.Also assert the content types on the canonical host, not just the status:
text/plain; charset=utf-8andapplication/pgp-keysare the actual requirement from #107/#109, and a 200 with the wrong type would still be a regression.Note
The alternative — a Cloudflare WAF skip rule for GitHub's IP ranges — is a manual console change (
Manual-Setup-Checklist.mdterritory) and widens the site's exposure to make a test convenient. Not worth it when the origin probe covers the same ground.