Write hash in pre-commit hook for predicable viewer.js location, build JS in CI

[borkdude]

Fixes #102

@mk Ready for review.

[mk]

Thank you, this looks good and getting this should nicely improve the workflow. Only wondering if we can do a pass on the names here to make it clearer what this is for.

Some ideas:

• write-hash → write-viewer-resources-hash
• hashing.clj → viewer-resources-hashing
• refresh-cdn → build+upload-viewer-resources
• front-end-hash.txt → viewer-js-hash.txt, or viewer-resource-manifest if we turn it into the same map that clerk.resource_manifest is.

Alternatives to resources could be assets (which I know you don't like) or to stay as narrow as possible viewer-js. Though I do want to add building a css file here very soon.

Note that in clerk.resource_manifest we already use a custom css if that key is set.

Now thinking that we should unify those names, so either change the clerk.resource_manifest system property to become clerk.viewer_resource_manifest or drop the viewer from the suggestions above. Leaning towards with viewer, wdyt?

[borkdude]

@mk Excellent suggestions. I also renamed the bb dir to src-bb which is maybe a better name. I processed all suggestions. We can do more renaming in the future as necessary. I'll fix the build as renaming things almost always is paired with build failures :P.

[borkdude]

@mk Implemented the changes. One thing I'm wondering about. What if we get hash collisions, e.g.

gs://nextjournal-cas-eu/data/lookup/2MnmwsYfak9x5j6cXDBB56uRiheT

already exists, but was produced from a different set of files a year or so ago. Should we do additional cache invalidation?

[borkdude]

As discussed: collisions aren't considered a problem. Ready for squash/merge!

[mk]

Some remarks which we might want to address in a follow-up.

[borkdude]

Thanks, will resolve in follow up.

[borkdude]

Processed all comments and pushed to the ui tests branch (to avoid merge conflicts, rebasing, etc, I'd like to limit the work in progress).