ci: using built-in caching from setup-node

[dlockhart]

Now that this is built into the setup-node action, seems like we can save some code by using it. Not sure whether no longer skipping the NPM install step will make things super slow, but I'll test that out.

[dlockhart]

The installation step (which now always runs) seems to take between 10-20 seconds when there's a cache hit, compared to being skipped entirely before. That seems like an OK trade-off to me to reduce the size & complexity of the workflows.

[svanherk]

Action will try to search package-lock.json or yarn.lock (npm 7.x supports yarn.lock files) files in the repository root and throw error if no one is found. The hash of found file will be used as cache key (the same approach like actions/cache recommends).

If I'm understanding the above correctly (from the caching PR), the cache busting works the same as what we had before?

[dlockhart]

Yes, it's actually slightly better in that they're putting the environment in the cache key as well.

The main difference is that they're not surfacing whether or not there was a cache hit, so we can no longer skip steps based on that. Which they don't seem to think is a problem, and doesn't seem to add significant time to our builds from my testing. If anything it lets us combine a few of our "install" steps into one, which I've done here.

[svanherk]

Yeah, I agree the cleanup of the workflows is worth it, much nicer. We can keep an eye on things to see if the install times get worse over time, but ideally GitHub Actions gives us the ability to retrigger individual jobs. Then it matters even less, if I can retrigger the Sauce job and not all the others.

[ghost]

🎉 This PR is included in version 1.152.1 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀