CI 빌드 캐시 도입

[hyoseong1994]

현재 integration.yml, deploy.yml에는 캐시가 전혀 없어 매 실행마다 의존성 설치·브라우저 다운로드·Vite 번들을 처음부터 반복하고 있습니다.
콘텐츠/다이어그램/컴포넌트가 늘어날수록 CI 시간이 선형으로 증가하므로, 프레임워크 변경 없이 actions/cache로 미리 대비합니다.

▎ 관련: #89 (Astro 마이그레이션 검토), #90 (loader cache 논의)
▎ OG 이미지 캐시(public/og)는 preview.yml에 이미 적용되어 있어 이 이슈 범위에서 제외합니다.

의존성 캐시

bun install 결과를 캐시합니다. key가 bun.lock 해시라 lockfile이 바뀔 때만 무효화되어 정합성 문제가 없습니다. 세 워크플로우 어디에도 없는, 가장
기본이자 효과가 큰 캐시입니다.

• uses: oven-sh/setup-bun@v2
• uses: actions/cache@v4
  with:
  path: ~/.bun/install/cache
  key: bun-${{ runner.os }}-${{ hashFiles('bun.lock') }}
  restore-keys: bun-${{ runner.os }}-

Playwright 브라우저 캐시

rehype-mermaid가 다이어그램 렌더에 사용하는 헤드리스 브라우저 다운로드를 재사용합니다. 다이어그램을 포함한 글이 늘어나면 이 다운로드 비용이
커집니다.

• uses: actions/cache@v4
  with:
  path: ~/.cache/ms-playwright
  key: playwright-${{ runner.os }}-${{ hashFiles('bun.lock') }}

Vite 빌드 캐시

node_modules/.vite의 사전 번들(pre-bundle) 결과를 재사용합니다. RR7 스택에서 Astro loader cache에 개념적으로 가장 가까운 계층으로, 의존성이나 빌드
설정이 그대로면 재번들을 건너뜁니다.

• uses: actions/cache@v4
  with:
  path: node_modules/.vite
  key: vite-${{ runner.os }}-${{ hashFiles('bun.lock', 'vite.config.ts') }}
  restore-keys: vite-${{ runner.os }}-

적용 대상

• 대상: integration.yml, deploy.yml

[SimYunSup]

세 캐시(bun install / Playwright / Vite) 반영 감사합니다. 다만 node_modules/.vite는 의존성 사전 번들 캐시라서, MDX를 remark/rehype로 변환하거나 mermaid 다이어그램을 렌더하는 비용까지 캐시되진 않는 것 같아요.

콘텐츠 파일 해시를 key로 변환/렌더 결과를 캐시해서, 파일이 안 바뀌면 재사용하면 어떨까요?

구체적으로는:
변환/렌더 결과(예: 컴파일된 MDX, 렌더된 다이어그램 파일)를 actions/cache의 path로 지정
key는 콘텐츠 디렉터리 해시로 구성해 콘텐츠 변경 시에만 캐시 미스가 나도록 설정
캐시가 적중하면 안 바뀐 파일은 재변환/재렌더 안 함

이 부분은 #91 스코프에 넣는 게 나을지 별도 이슈로 분리하는 게 나을지 궁금합니다. 어떻게 생각하시나요?

[hyoseong1994]

처음에 잘못 이해해서 node_modules/.vite만 캐시하면 되는줄 알았는데 아니군요
이슈를 분리하는게 좋을것같아 CI 빌드캐시도입과 CI MDX 컴파일 결과 캐시 도입으로 나누었습니다.

감사합니다.