Config node module caching in ci workflow

[mokhs00]

Close #67

Summary

• ci 속도 향상을 위해 node module caching을 추가합니다.
• 대충 이 문서를 참고함 -> https://docs.github.com/en/enterprise-server@3.6/actions/using-workflows/caching-dependencies-to-speed-up-workflows
• 근데 self-hosted runner를 사용하는 게 아니라 효과가 없을지도..? github에서 같은 인스턴스를 할당해주면 확률적으로 효과가 있을 순 있어보임

[korECM]

setup-node Action에서 기본적으로 cache 기능을 제공해주는 것으로 알고 있어서 별도로 필요한게 아니라면 setup-node 이용해서 캐싱하는 것도 좋을 것 같아요.

https://github.com/actions/setup-node#caching-global-packages-data
->
The action has a built-in functionality for caching and restoring dependencies. It uses actions/cache under the hood for caching global packages data but requires less configuration settings. Supported package managers are npm, yarn, pnpm (v6.10+). The cache input is optional, and caching is turned off by default.

steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
  with:
    node-version: 16
    cache: 'npm'
- run: npm ci
- run: npm test

[mokhs00]

@korECM 아닛 이런 게 있다니.. 혼자 꿀빨고 계셨네요? ㅋㅋㅋㅋㅋ~

[korECM]

@mokhs00
여담이지만 self-hosted runner를 사용하지 않아도 충분히 캐시 효과를 볼 수 있어요.

제가 생각하는 원인은 다음과 같은데 팩트 체크를 한 것은 아니라서 틀릴지도..?

1. 패키지의 종속성 분석 및 컴파일 과정 없이 모듈 파일을 다운로드만 하면 되므로 빠름
2. github action 캐시는 GitHub-owned cloud storage에 저장되는데 내부 구조는 모르지만 github의 runner 입장에서 npm registry보다 github storage에서 더 빠르게 받아올 수 있지 않을까..?
3. 패키지 별로 따로 다운로드를 진행하는 것과 하나의 큰 파일을 받는 부분에서도 속도 차이가 발생할 것 같아요

[Yaminyam]

액션탭의 왼쪽에 메뉴바에서 캐시탭을 확인 할 수 있고 관리도 가능합니다. 최대 10기가까지 저장 가능하고 넘어가면 가장 오래 사용안된 캐시부터 자동으로 삭제됩니다