chore: Use setup-node action to cache dependencies

[jongwooo]

Signed-off-by: jongwooo jongwooo.han@gmail.com

Description

Updated workflows to cache dependencies using actions/setup-node. setup-node@v3 or newer has caching built-in.

About caching workflow dependencies

Jobs on GitHub-hosted runners start in a clean virtual environment and must download dependencies each time, causing increased network utilization, longer runtime, and increased cost. To help speed up the time it takes to recreate files like dependencies, GitHub can cache files that frequently use in workflows.

Solutions

Node.js projects can run faster on GitHub Actions by enabling dependency caching on the setup-node action.

AS-IS

- uses: 'actions/setup-node@v3'
  with:
    node-version: '16'

TO-BE

- uses: 'actions/setup-node@v3'
  with:
    node-version: '16'
    cache: 'npm'

It’s literally a one line change to pass the cache: 'npm' input parameter.

References

• https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
• https://thearchivelog.dev/article/caching-dependencies-to-speed-up-workflows/

[sethvargo]

Hi @jongwooo

I'm not sure I understand the value of caching the dependencies.

1. We don't have a ton of dependencies - the total download time is ~2s, which is negligible in the overhead of CI runs. Furthermore, the downloads can take place in parallel. GitHub's cache is a giant tarball which cannot be downloaded in parallel, so it would strictly increase storage and maintenance costs, potentially with negative benefit. There have also been numerous issues with GitHub Actions cache once caches exceed 2GB in side.

   I think there may be a misconception that GitHub caches just magically attach to the runner, but that's not the case. The cache still must be downloaded via HTTP from GitHub's servers. Yea, it's compressed, but so are the packages from NPM.

2. The dependencies are NPM packages and they are edge cached at the CDN. As noted above, we have a very limited number of dependencies and they are downloaded in parallel. This is not a source of network congestion or a significant delay in the CI process. Furthermore, the actual tests often call eventually consistent upstream APIs, so even if it saved time (it doesn't), saving those few seconds isn't super helpful for this project. Also, of note, GitHub owns npm.

3. There's an argument to be made that caching would improve our CI availability, but that doesn't help much since any user of our GitHub Action would also depend on NPM. Furthermore, our experience is that NPM has less downtime than GitHub Actions.

[jongwooo]

@sethvargo Thank you for your comment! Based on this information, I agree that closing the PR and not implementing caching is the appropriate action.