더 빠른 빌드를 위한 의존성 캐싱

지속적 통합에 걸리는 시간의 대부분은 매 실행마다 같은 의존성을 다운로드하고 설치하는 데 사용됩니다. 캐싱은 실행 사이에 의존성을 저장하므로 이후 빌드에서 작업 결과를 재사용할 수 있으며, 파이프라인 시간을 크게 줄이는 경우가 많습니다.

GitHub는 actions/cache를 제공합니다. 캐시할 경로와 캐시 항목을 식별하는 키를 지정하면 됩니다. 캐시 적중 시 경로를 복원하고, 그렇지 않으면 작업이 끝난 후 경로를 저장합니다.

캐시된 내용이 변경되어야 할 때만 키가 변경되어야 합니다. 잠금 파일을 해시 처리하는 방식이 이상적입니다. 잠금 파일이 새로 생성되면 의존성도 새로워지므로 새로운 캐시 항목이 만들어집니다.

restore-keys는 대체 접두사를 제공합니다. 정확한 키로 찾지 못하면 작업이 키가 해당 접두사로 시작하는 가장 최근의 캐시를 복원하여, 일부 의존성이 준비된 상태로 시작할 수 있습니다.

정확한 키가 일치하면 캐시 적중이 발생하고 경로가 복원됩니다. 미적중이면 작업이 정상적으로 실행되고, 마지막에 기본 키를 사용하여 캐시가 저장되므로 다음에 바로 사용할 수 있습니다.

언어 설정 작업에는 캐싱 기능이 내장되어 있습니다. 노드의 경우 setup-node에서 cache: npm을 사용하면 의존성 캐시를 자동으로 처리하므로 별도의 캐시 단계가 필요하지 않습니다.

가능하면 설치된 node_modules가 아니라 패키지 관리자의 다운로드 디렉터리를 캐시하십시오. 다운로드 캐시는 이식성이 높고, 설치 단계에서 무결성도 계속 확인하기 때문입니다.

• 노드: ~/.npm
• 파이썬: 패키지 설치 관리자 캐시
• Java: ~/.m2 또는 Gradle 캐시

캐시는 브랜치별로 범위가 정해지며 기본 브랜치로 대체할 수 있습니다. 또한 저장소별 크기 제한이 있습니다. 사용하지 않는 캐시는 시간이 지나면 제거되므로, 자연스럽게 교체되는 키를 설계하십시오.

키가 절대 변경되지 않으면 오래된 의존성이 제공될 수 있습니다. 업데이트 시 캐시가 자동으로 무효화되도록 항상 키를 잠금 파일의 해시에 연결하십시오.

운영 체제나 버전에 걸쳐 행렬 빌드를 수행할 때는 키에 runner.os와 버전을 포함하십시오. 그러면 각 변형이 충돌하지 않고 올바른 별도 캐시를 사용합니다.

캐싱 전후의 작업 시간을 비교하고 로그에서 캐시 적중 표시를 확인하십시오. 적중률이 지속적으로 낮다면 키가 너무 자주 변경되고 있다는 뜻입니다.

의존성 캐싱에 대한 이해도를 확인해 보십시오.

의존성 캐싱으로 지속적 통합을 더 빠르게 만들었습니다. 잠금 파일 해시를 사용하는 키와 restore-keys 대체 기능을 갖춘 actions/cache 작업, 설정 작업에 내장된 캐싱, 캐시할 항목의 선택, 행렬 키에 운영 체제와 버전 포함하기, 키를 잠금 파일에 연결하여 오래된 캐시 방지하기를 배웠습니다.