react
react copied to clipboard
facebook
CI: try to make caching more reliable
~/.yarn/cacheis now restored from an hierarchical cache key, if no precise match is found, we fallback to less precise ones.- The yarn install in
fixtures/domis also cached. Notably, is utilizes the cache from root, but stores into its more precise key. - Steps running in root no longer have a
yarn installand rely on the cache from the setup step. I think this is something we should keep an eye on if these caches can be missed. If so, we might want to do yarn installs in each job, but then should also restore the yarn cache there. Yarn installs w/o cache restoration need to be avoided.
I have 2 working configurations now:
yarn installeverywhere, no more caching ofnode_modules. This simplifies the config and makes it more robust. sample run- Cache
node_modulesincluding the node_modules in each package. This avoids theyarn installwhich takes about 30s per step, but it's a bit fragile as it lists out all the node_module directories for each package. I also think there's a possibility of a cache injection by a malicious PR, so I included the epoch in the key to give every build its own cache. sample run
I'd prefer option 2 as 30s increases the feedback loop by 50% for most of the tests.
@kassens An additional thing we could try is to retry the yarn install command if we see one of those 503 errors, which could still happen despite caching.
We could also try to see if caching is working with running the subsequent yarn install commands with the --offline flag which I think will error if it has to reach out to the network. If there are then maybe we need to make the initial setup job actually install all the packages.
@poteto if we remove the yarn installs from all subsequent steps and rely on node_modules caching, I don't think we need the offline flag. I do like the idea of adding a retry though for the yarn install at the very beginning. I'll add that here too.