Repository navigation
Clean up orphaned pages on deploy #21
Description
Activity
Got another report of this today
When searching "apppack reviewapps" and clicking on this link "https://docs.apppack.io/how-to/review-apps/"
It takes me a different format then "https://docs.apppack.io/how-to/apps/review-apps/"
Clicking on "Install the Command Line Interface (CLI)" in the what i assume is some legacy url returns a 404.
Just a heads-up 👍
make deploynow passes--deleteon the secondaws s3 syncpass, so keys the build no longer produces are removed. It's on the second pass specifically because the first is filtered to--exclude "*.html", and that filter applies to deletion candidates too — orphaned pages would survive it. Uploads happen first and only keys absent from the build are removed, so no valid page goes missing at any point.Since that makes the deploy destructive,
deploynow depends on acheck-buildtarget that refuses to run whenpublic/clearly didn't finish building — missingindex.html, or fewer than 50 HTML pages. Verified that a bad build reaches zeroawscommands. The floor is on the source being sane rather than on the deletion count, since the first run will legitimately remove a large backlog of orphans.Worth watching that first deploy's output for the same reason.
This is served from Cloudfront -> S3. The docs upload each time, but don't remove any orphaned pages. That should be an automated part of the deploy. We should do a sync instead of a naive delete all and upload to having valid pages go missing for a small window.