perf(ci): build-cache 워밍이 캐시 키가 그대로인 develop push 에서도 11분씩 돈다 — 저장이 원천 불가한 run #1047

#996 (PR #1037) 로 들어간 build-cache-warm.yml 의 잔존 결함이다. 설계는 맞고 트리거 범위가 틀렸다.

증상

머지 직후 워밍 run 2건이 둘 다 성공했지만 아무것도 저장하지 못했다.

Basic caching restored entry with key `setup-java-Linux-x64-gradle-3b1d9c72…`. Save was skipped.

원인 — 저장이 가능한 조건이 정해져 있다

actions/setup-java 의 gradle 캐시(= setup-gradle 의 cache-provider: basic)는

• 키를 빌드 스크립트 해시로 만든다 — **/*.gradle*, **/gradle.properties, **/gradle-wrapper.properties, buildSrc/**/Versions.kt, buildSrc/**/Dependencies.kt, gradle/*.versions.toml, **/versions.properties
• restoreKeys 를 두지 않는다 (“No restoreKeys is set, to start with a clear cache after dependency update.”)
• exact match 로 복원하면 저장을 건너뛴다 (matchedKey === primaryKey)

그래서 실제 동작은 두 갈래뿐이다.

키가 그대로인 push 에서 도는 워밍 run 은 저장이 원천적으로 불가능하다. 11분을 쓰고 버린다. develop push 는 PR 을 머지할 때마다 나므로 빈도가 높다 — 2026-08-24 에는 10:52~10:56 사이에만 3회였다.

워밍이 필요한 자리는 그대로 유효하다

restoreKeys 가 없으므로 빌드 스크립트가 바뀌면 build cache 가 통째로 리셋된다. 같은 날 develop 스코프에 키가 5개 생겼으니 리셋이 5번 있었고, 그 직후 첫 PR run 들이 빈 캐시를 만난다. 워밍의 가치는 정확히 그 자리에 있다 — 없애는 것이 아니라 그때만 돌게 하면 된다.

범위

• build-cache-warm.yml 의 push 트리거에 paths 를 걸어 캐시 키 해시 입력이 바뀐 push 에서만 돌게 한다. 패턴은 위 7종과 일치시킨다 — 좁으면 캐시가 영영 안 채워지고, 넓으면 낭비가 남으므로 정본을 그대로 따른다.
• workflow_dispatch 는 유지한다(수동 워밍 경로).
• 정책 테스트로 고정한다 — paths 목록이 setup-java 의 키 입력과 어긋나면 실패하도록.

완료 조건

• 빌드 스크립트를 건드리지 않은 develop push 에서 워밍 run 이 생성되지 않는다.
• 빌드 스크립트가 바뀐 develop push 에서는 워밍이 돌고, 그 run 의 post 로그가 Save was skipped 가 아니라 저장 성공으로 남는다. run 링크와 함께 수치를 이 이슈에 남긴다.
• 그 직후 PR run 에서 FROM-CACHE 가 보고된다.

근거

• setup-java 캐시 구현: https://github.com/actions/setup-java/blob/main/src/cache.ts
• setup-gradle 캐시 문서: https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#caching-build-state-between-jobs
• 실측 상세: perf(ci): PR 검증 4개 job이 같은 debug variant 를 각자 컴파일 — build cache 가 전역 off #996 (2026-08-24 코멘트 2건)

관련

• perf(ci): PR 검증 4개 job이 같은 debug variant 를 각자 컴파일 — build cache 가 전역 off #996