I tried removing the rsync of only the root node_modules folder, and this seemed to help (no more deploy failures with “Cause of build failure could not be determined”).
Maybe the above error is actually a bug in Render’s deploy scripts: try rsyncing node_modules to $XDG_CACHE_HOME and watch all Render deploys fail.
However, removing rsync for the root node_modules didn’t help with the cache misses:
Jan 8 12:39:45 PM CACHE MISS packages/website/.cache
Jan 8 12:39:45 PM CACHE MISS packages/website/public
It seems like there’s nothing in the cache actually…
Jan 8 12:35:00 PM ==> Downloading cache...
Jan 8 12:35:07 PM ==> Detected Node version 16.2.0
@Ralph is it a problem if I’m rsyncing deep directories recursively like this? Or is it an issue that the paths in $XDG_CACHE_HOME partially match the paths on disk? (for example, packages/website is a folder in the Git repo, and $XDG_CACHE_HOME/packages/website/node_modules are the node modules cached for that Yarn workspace)
One potential solution would be for the save_render_cache function to change the slashes in the paths to some other separator (eg. changing / to - or something), to avoid these problems. And then for restore_render_cache to convert back to slashes. But I would only go ahead with such a solution if you can confirm that these scenarios I described above are problematic.
Edit: Ah interesting, it seems that if I remove all the references to the recursive node_modules, then after 2 or 3 deploys the Gatsby cache starts hitting instead of missing (see below). I’m not sure why it’s not instant though - do you have any clue here? Maybe Render cache takes a while to warm up / be ready?
Jan 8 03:13:34 PM CACHE HIT packages/website/.cache, rsyncing...
Jan 8 03:13:45 PM CACHE HIT packages/website/public, rsyncing...