Repository navigation
9: fix: route the fonts directory to the bucket and check it after deploy - #33
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What. Routes
/fonts/*to the bucket, dropsrobots.txtandsitemap.xmlfrom that list, andadds a post deploy check that every face the stylesheet asks for actually resolves.
Why. All five faces returned 404 in production after #32. The site rendered in a fallback and
looked unfinished.
s3_patternsincloudfront.tflisted onlyBUILD_ID,_next/static/*,favicon.ico,robots.txtandsitemap.xml, so/fonts/chivo-400.woff2went to the serverfunction, which has no route for it and answered 404.
robots.txtandsitemap.xmlcome off that list for the opposite reason: nothing exists at thosekeys, so Origin Access Control refused them and CloudFront returned 403. A 403 on
robots.txtisworse than a 404 for a crawler. They will be served by the application in #9.
On why the tests did not catch it. They could not.
next startservespublic/directly, so amissing route in CloudFront is invisible to any application test. That is the gap this adds a check
for, in the deploy workflow where it belongs: read the stylesheet off the deployed page, extract
every
url(/fonts/...), and require a 200 for each.The application test added here guards the other half, a face referenced but absent from the build.
I mutation checked it by deleting
chivo-700.woff2and watching it report/fonts/chivo-700.woff2 did not resolve: expected 404 to be 200.Part of #2. Relates to #9.