cache executorch builds on runners

[mikekgfb]

As suggested by @malfet

[mikekgfb]

This is the gt explanation for caches, https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#cache-hits-and-misses

but we don't have an example of how the cache is populated.

[metascroy]

Summarizing offline convo:

• cache all of et-build
• Do something like "basically python setup.py bdist_wheel -d /path/to/wheel-out-cache-dir/"

cc @dbort @larryliu0820

[larryliu0820]

Short term:

• Cache et-build/ since it contains build artifact (static libraries) as well as source code
• Enable executorch nightly build so we can download pybind.so directly. For a lot of CI jobs that's the only thing we need.
• Make sure we pin on ExecuTorch nightly and when we checkout ExecuTorch source we checkout the same commit as nightly.

Long term:

• From ExecuTorch perspective, a lot of the libraries are already included in pybind.so, we should provide infra to link pybind.so into applications. Having pybind.so == libexecutorch.a + libxnnpack_backend.a + a lot more. Feel like it should become the libtorch.so in ExecuTorch.

[mikekgfb]

it seems it’s straightforward — indicate what the cache should cache, how to get a cache key (I guess so we can figure out changes? git version and hardware system, probably), and it will just make things appear (if it has it), and you can check whether cache checkout was successful, or else build it

No saving required, the build system will capture all the files you tried to retrieve and push them into the cache when the run finishes