ci(workflows): bump 'setup-node' to v2 and use 'cache' option

[oscard0m]

Description

• Add cache to workflows using actions/setup-node
• Bump actions/setup-node to v2 to give support to this cache option

Context

setup-node GitHub Action just released a new option to add cache to steps using it.

You can find the details here: https://github.blog/changelog/2021-07-02-github-actions-setup-node-now-supports-dependency-caching/

Fix #44898

---

🤖 This PR has been generated automatically by this octoherd script, feel free to run it in your GitHub user/org repositories! 💪🏾

---

Migrated from #44897 due to indentation changes problem (GitHub was still showing indentation changes even I was restoring back the original indentation)

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[oscard0m]

First - it'd be super nice if you could split the formatting differences into a separate PR - I can't tell if the whitespace changes are good or bad.

👍🏽 Ok to remove indentation.

Second - the GH actions build is currently a bit simpler than the DevOps one because it lacked caching - while caching most dependencies is fine, tslint (probably eslint and ts-related plugins nowadays) and typescript in the tree need to be cache-busted explicitly, so we always get the latest nightly of them. The DevOps build (which has caching) accomplishes this by explicitly uninstalling and reinstalling those dependencies after the initial (cached) install. I'm not sure if the node setup action's caching strategy is amenable to this, but we'd want it to do the same if it caches (since if we stop building against nightly tslint/eslint/typescript, we're liable to break the combination of them and not know when).

If I'm understanding correctly:

• ci.yml and release-branch-artifact.yml are the ones with this npm uninstall use case. When you say build and DevOps you refer to these ones?

What I suggest to do is:

• We can open a different issue and do the research to see if setup-node is supporting this "selective cache" (so we can apply it for typescript and tslint).
• To move forward with the rest of the GitHub Actions with this change and rollback the cache option for ci.yml and release-branch-artifact.yml
  • ⚠️ A new change I had to apply is to bump setup-node to v2 to give support to this cache option

Let me know what do you think @weswigham and @RyanCavanaugh

[sandersn]

@weswigham you reviewed #44897; this is the followup to that.

[weswigham]

My comment from the other PR - about needing cache-busting for certain packages that we pin to latest like in the DevOps builds - still stands.

[sandersn]

Requesting changes to make the current status of the PR explicit.

[sandersn]

@oscard0m is @weswigham's request feasible for you to do? I don't think we'll able to take this PR without it. =(

[oscard0m]

From what I've read in setup/node ADR the cache option only covers the basic use-case of caching all the dependencies. For "more sophisticated" setups like the one of non-caching some dependencies should be covered combining actions/cache (and I'm not sure if that would be possible).

I just created an issue to actions/setup-node to ask more details on what is implemented by this cache option and actions/cache to see if there is a way to partially cache dependencies: actions/setup-node#321

---

@weswigham
I did not get clarified my questions here so I'm not sure if my changes would have sense to some of the workflows or they don't have sense for none of them (in case there is no easy solution with actions/cache or actions/setup-node).

[oscard0m]

Issue replied by a contributor: actions/setup-node#321 (comment)
There is no way today to do partial caching with actions/setup-node or actions/cache so I guess we can undo these changes for the GitHub Actions doing this uninstall step.

After a bit of research on npm existing solutions for cleaning the cache I discovered npm@7.21.0 added support for npm cache rm <key>. I would say we can keep On Hold this part until npm 7 becomes the default version as I suggested in the original issue discussion.

I keep waiting for your feedback regarding the other actions not uninstalling packages as a step. :)

[vinayakkulkarni]

LGTM

[weswigham]

Just gunna close this and someone can come forward with another version that does cache busting where needed. Or not; this isn't exactly a high priority thing.