Cache lattice in CI

The `build lattice` job is a source of frustration because it is a
dependency for building additional jobs in CI, has a wildly varying
runtime--anywhere from 2-7 minutes to finish--and doing a yarn install
&& yarn build is the most CPU/memory hungry part of our CI pipeline.

To address this, I'm hashing the lattice directory, and using the hash
to look for an artifact in S3 which can be downloaded instead of
building the web ui from scratch each commit.

This cache happy path (cached file exists in S3) cuts the time of this
job down to somewhere below 2 minutes even with many concurrent jobs and
pipelines running.

This also gives us the ability to pull built versions of lattice
associated with the commits that produced them, because each new file in
S3 also gets a zero-byte file with the long name of the git revision
(e.g., a zero-byte file called
`924a152ae92372a178bd0fc32b411612b995a6a1` will be stored in S3 so it is
possible to know which commit changed the lattice directory.)

Invalidating this build cache is as simple as deleting a specific key
(or all keys) at s3://molecula-artifact-storage/lattice/<hash> (or
s3://molecula-artifact-storage/lattice/*).

.gitlab/.gitlab-ci.yml

@@ -135,13 +135,46 @@ build lattice:
   stage: test
   image: node:14
   variables:
+    AWS_PROFILE: "service-fb-ci"
+    AWS_ACCESS_KEY_ID: $AWS_FBCI_ACCESS_KEY_ID
+    AWS_SECRET_ACCESS_KEY: $AWS_FBCI_SECRET_ACCESS_KEY
     CI: "false"
   rules:
     - if: '$CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "schedule" || $CI_PIPELINE_SOURCE == "web"'
+  before_script:
+    - curl -sS "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
+    - unzip -qq awscliv2.zip
+    - ./aws/install
+    - aws --version
+    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
+    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
+    - aws configure set region "us-east-2"
+    - aws configure set aws_profile $AWS_PROFILE
+    - aws sts get-caller-identity # ensure we have a valid AWS login
   script:
     - cd lattice
-    - yarn install
-    - yarn build
+    - cache=$(find . -type f -print0 | sort -z | xargs -0 sha1sum | sha1sum | cut -d ' ' -f 1)
+    - echo "'$cache'"
+    - echo "looking for s3://molecula-artifact-storage/lattice/$cache/build.tar.gz"
+    # if is for if we had a cache object in S3
+    # else is for if we didn't have a cache object (and have to build).
+    - |
+      if aws s3api head-object --bucket molecula-artifact-storage --key "lattice/$cache/build.tar.gz"; then
+        # download object, extract, name the folder `build`
+        aws s3 cp "s3://molecula-artifact-storage/lattice/$cache/build.tar.gz" build.tar.gz
+        tar -xf build.tar.gz
+      else # cache file not found
+        yarn install --frozen-lockfile # CI needs to enforce that the lockfile doesn't need to be updated
+        yarn build
+        tar -czvf "$cache.tar.gz" build/
+        aws s3 mv "$cache.tar.gz" "s3://molecula-artifact-storage/lattice/$cache/build.tar.gz"
+        touch "$CI_COMMIT_SHA"
+        aws s3 mv "$CI_COMMIT_SHA" "s3://molecula-artifact-storage/lattice/$cache/$CI_COMMIT_SHA"
+      fi
+    - | # Ensure that we have build directory after the caching step
+      if [ ! -d build ]; then
+        echo "no build directory, erroring out" || exit 1
+      fi
     - mv build ../
     - cd ../
     - rm -r lattice
@@ -390,7 +423,6 @@ run go tests idk sasl:
   needs:
     - job: build amd container fb
 
-
 upload to sonarcloud:
   stage: nonblocking
   image: sonarsource/sonar-scanner-cli:4.7