PwrSnap

@adam_chal @vboykis pwrdrvr/configure-nodejs There is one example. Devs frequently get node.js module caching wrong. The default node-setup caching would cache the npm cache directory then still chug away for minutes doing an "install" that was supposed to just restore from the cache. This action gets it right. Use it in a job like the following that checks for the existence of the cache and tries to do NOTHING else, not even restore the cache or install node when the cache key exists. Isolate this job on it's own: reason - PRs if you do NOT have this job AND you kick of several parallel jobs that all need the cache (like on any PR that changes the key) they will all create the cache and try to save over it, completely removing the benefits of the cache on PRs that change the key. AND if the jobs that do this work fail, e.g. because of a flaky test after 3 minutes of setting up the deps, then the cache won't be saved because the job failed and replaying it will repeat the build. But when it's an isolated job it saves the cache and if you replay the later flaky jobs they will use the cache. Hope this helps. Note that things change, so perhaps some of this has gotten better. But these were the reasons I made this shared action. It is the only one that I have encountered that gets all these points correct. Granted, I'm sure someone has made an even better action. github.com/pwrdrvr/PwrSnap/actions/runs/382954682…