👷 Cache gatsby builds

[afranke]

This caches the .cache and public directories, as suggested by the Gatsby documentation (it’s worth noting we are still on 2.24).

From running the workflow several times for that commit, I can see that the cache is saved and restored, but I don’t notice a significant performance improvement. I suggest we merge it (assuming I didn’t break anything) and see how it behaves over a series of commits. I reckon worst case is we don’t save anything.

[callahad]

Looking at the logs I see:

Cache Size: ~0 MB (45 B)
Cache saved successfully
Cache saved with key: Linux-gatsby-build-1228543153

...so it looks like this isn't actually capturing and caching state?

[afranke]

Good catch, will investigate.

[afranke]

… and it seems obvious to me now that the working-directory (and therefore the paths) must be incorrect. 🤦‍♂️

[callahad]

For your initial run with a cold cache, the Gatsby step took 9m 41s, of which 6m 40s was "Gatsby Build."

I re-ran the workflow, and the Gatsby step completed in 2m 55s, of which 50s was "Gatsby Build."

This is effectively a no-op, since no content changed from what was already cached.

Caching itself seems to take on the order of ~10s to download, ~40s to upload. And the no-op Gatsby run was nearly a minute.

So it seems like a lower bound for Gatsby is ~2 minutes, and the workflow itself adds a fixed cost of ~2 minutes on top of that (pulling the Docker image, tarring and uploading artifacts, etc.)

So a best case scenario with Gatsby is probably 6 minutes end-to-end, including 2 minutes for the "Packaging" step at the end of the workflow.

Switching to Hugo or Zola would make the build step effectively instantaneous, eliminate the need to pull a 500 MB Docker Image shaving off over a minute, and remove the need for caching, saving another minute... so the best case scenario with Hugo is probably ~3 minutes end to end?

[afranke]

Right, halved build times, but also plain markdown files for content which makes editing easier. Migration seems indeed to be the way to go. I can still merge this in the meantime right?

[callahad]

Just to check... let's throw a commit with a page edit into this PR and see how long it takes to rebuild.

[callahad]

(And also double-check that the built artifact is actually identical to the same commit build without a cache. After that, we can revert the edit and merge.)

[afranke]

Just to check... let's throw a commit with a page edit into this PR and see how long it takes to rebuild.

The gatsby job of the run after I added a commit took 3m 55s (whole workflow took 6m 9s).

And also double-check that the built artifact is actually identical to the same commit build without a cache.

None of the gatsby artifacts are identical between before I implement cache, after I add cache, and after I add cache and make an edit.

Upon closer inspection, I see the changes are files like webpack-runtime-<somehash>.js{,.map} at the root of the public folder, and changes to their references like [[-src="/webpack-runtime-77f650ebf891b9cca23a.js"-]{+src="/webpack-runtime-028594c0cfd0c6d34d45.js"+} in all the html files.

I don’t know if those are supposed be “refreshed” like that on each build. Shall we proceed with the merge?

After that, we can revert the edit and merge.

I know it doesn’t have anything to do with the purpose of the MR, but it’s a change I’d reapply afterwards anyway, so does it make sense to just leave it in?

[callahad]

I know it doesn’t have anything to do with the purpose of the MR, but it’s a change I’d reapply afterwards anyway, so does it make sense to just leave it in?

I'd prefer to keep things separate just for hygiene sake, but I wouldn't block on it