测验：缓存键的设计

CI 캐시가 반드시 지켜야 하는 성질은?

• 캐시를 쓸 때와 지웠을 때의 실행 시간이 비슷하게 유지되어야 한다
• 캐시를 지워도 같은 산출물이 나와야 하고 시간만 줄어야 한다
• 캐시 항목이 저장소 한도 안에서 항상 유지되어야 한다
• 캐시가 모든 브랜치 사이에서 자유롭게 공유되어야 한다

캐시 열쇠에 잠금 파일의 해시를 넣는 가장 큰 이유는?

• 열쇠 문자열이 짧아져 저장소 한도를 덜 쓰게 되기 때문이다
• 잠금 파일이 없는 프로젝트에서도 캐시를 쓸 수 있게 되기 때문이다
• 캐시 항목이 축출되는 순서를 사람이 정할 수 있게 되기 때문이다
• 의존성이 바뀌면 사람이 손대지 않아도 열쇠가 저절로 달라지기 때문이다

restore-keys 같은 접두 대체로 캐시를 복원했을 때 주의해야 할 점은?

• 받아 온 내용이 지금 잠금 파일과 일치한다는 보장이 없다
• 접두 대체로 받은 캐시는 다음 실행에서 다시 쓸 수 없다
• 접두 대체를 쓰면 정확히 맞는 열쇠를 더는 찾지 않는다
• 접두 대체는 같은 브랜치에서 만든 캐시만 대상으로 삼는다

시험 보고서와 커버리지 결과를 캐시가 아니라 산출물로 올려야 하는 이유는?

• 산출물이 캐시보다 압축률이 좋아 저장 공간을 덜 쓰기 때문이다
• 캐시는 같은 파이프라인 안에서만 읽을 수 있기 때문이다
• 캐시는 축출될 수 있어 실패한 그 순간의 증거가 사라지기 때문이다
• 산출물은 다음 실행에서 자동으로 복원되어 재사용되기 때문이다

플랫폼이 캐시의 브랜치 범위를 좁게 제한하는 이유는?

• 브랜치가 많아지면 캐시 열쇠 충돌이 자주 일어나기 때문이다
• 브랜치마다 도구 판이 달라 캐시 형식이 호환되지 않기 때문이다
• 브랜치별로 나눠야 캐시 압축과 복원 속도가 빨라지기 때문이다
• 아무 브랜치나 저장하면 누구나 이후 빌드 결과에 손댈 수 있기 때문이다

캐시 열쇠를 커밋 단위로 잘게 쪼갰을 때 흔히 벌어지는 일은?

• 열쇠가 길어져 캐시 저장 단계가 열쇠 길이 제한에 걸린다
• 캐시 항목이 늘어 서로를 밀어내면서 적중률이 오히려 떨어진다
• 복원 단계가 모든 열쇠를 훑느라 실행 시간이 두 배로 늘어난다
• 같은 커밋을 다시 돌릴 때 캐시가 무효화되어 매번 새로 받는다