[ci] Use NX caching to speed up CI

[nolanlawson]

We could be using the NX cache in CI (Nucleus, GitHub Actions) so speed up tests.

In the past, though, we've run into issues with the NX cache becoming out-of-date and causing hard-to-debug errors. So we should be careful to do this correctly.

This would speed up our builds by ~60 seconds per job.

[AllanOricil]

:(

[AllanOricil]

@nolanlawson
since caching isn't an option what if you guys use a more powerful machine for builds?

[AllanOricil]

I opened a feature request in the nx repo to see if they could create their own action to enable saving/restoring their cache during builds.

[AllanOricil]

nrwl/nx#20327

[AllanOricil]

If there wasn't that issue of not being able to reuse cache hits from different machines, it would be possible to cache each task result as its own cache with a fixed key, and then update it every time nx detects a cache miss for that particular task

The workaround to update a github actions cache with a fixed key is here (I did not test, but there are people saying it works):
actions/cache#342

It is possible to create a list of cache misses during a build using ./.nx-cache/run.json.

With this list we could iterate over each item and then recreate its cache in Github Actions using this workaround.

[AllanOricil]

There is an env variable to disable the unknow local cache

NX_REJECT_UNKNOWN_LOCAL_CACHE=0

[AllanOricil]

There is an env variable to disable the unknow local cache

NX_REJECT_UNKNOWN_LOCAL_CACHE=0

I think it would be possible to create a cache for each task run using a key created with the following information:

• sha256 of tarbal of the package folder (compute a hash from a tarbal with files sorted)
• yarn.lock from the root

[nolanlawson]

I would be a bit uncomfortable turning this flag on. It looks like it's not recommended for security reasons.

The savings would also be <60s of build time per GitHub Action. I'm not sure it's worth the risk…