Rebuilds Caching (Rebased) #1156
Closed
Conversation
This file contains 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
This way the code doesn't depend on the source file's relative directory.
I'm not sure if there's any rate limits in the stack that will cause this to break, but on first blush this looks like a quick and easy improvement. The cached folders are also now accessed by a shared array that is hard-coded for now. This both makes them easier to work with uniformly and open to sourcing directories from elsewhere in the future.
I believe the crux of what keeps this PR from working is that `public` and `.cache` the folders were being uploaded to `public` and `,cache` the S3 prefixes when the site is deployed from the root prefix. This change alters how the cache directories are stored: now as tuple pairs with the local directory in slot 0 and a string that's appended to the base prefix in slot 2. `public` work with the root prefix and the `.cache` folder works with the root prefix with `-cache` appended to it such that it's another "folder" that doesn't get downloaded with the root prefix. I find the tuple syntax more concise, but I'm open to changing it if we prefer objects for better grokking at a glance. This change also moves the responsibility of cache culling into an `onPostBuild` Gatsby hook. This means we don't have to parse the sitemap XML after the fact, and as such the XML parser used to do it is removed. Since this replaces `cleanUpPageData`, it also invalidates the whole `page-data-utils` file which has been removed.
|
Just for anyone else coming into this PR, it was meant mostly to generate the deploy preview. It currently doesn't work with our build system, and I'm trying to get it to do so via other means. I'll probably close this and open another one later when I have something more functional. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a continuation #1150 opened up against master instead of the other rebuilds-caching branch. I wasn't thinking about how rebasing my fork's branch onto master would cause havoc with PRs that already exist.
I could probably rebase what I have now back to the point where #1134 starts, but a new PR onto master seems like an easier option.