CI/CD 캐싱 예시

CI/CD 캐싱 예시에 대해 설명합니다.

캐싱을 사용하면 작업이 실행될 때마다 종속성과 빌드 아티팩트를 다운로드하지 않아도 됩니다. 캐싱은 이전에 다운로드한 콘텐츠를 재사용하여 CI/CD 파이프라인 속도를 높입니다. 더 많은 예시는 GitLab CI/CD 템플릿 을 참조하세요. 캐시 전략 # 이 예시들은 작업 및 브랜치 간에 캐시를 공유하는 다양한 접근 방법을 보여줍니다. 동일 브랜치의 작업 간 캐시 공유 # 각 브랜치의 작업이 동일한 캐시를 사용하도록 하려면 key: $CI_COMMIT_REF_SLUG 로 캐시를 정의합니다: cache: key: $CI_COMMIT_REF_SLUG 이 구성은 캐시를 실수로 덮어쓰는 것을 방지합니다. 그러나 머지 리퀘스트의 첫 번째 파이프라인은 느립니다. 브랜치에 커밋이 다음에 푸시되면 캐시가 재사용되고 작업이 더 빠르게 실행됩니다. 작업별 및 브랜치별 캐싱을 활성화하려면: cache: key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG" 스테이지별 및 브랜치별 캐싱을 활성화하려면: cache: key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG" 다른 브랜치의 작업 간 캐시 공유 # 모든 브랜치와 모든 작업에서 캐시를 공유하려면 모든 것에 동일한 키를 사용합니다: cache: key: one-key-to-rule-them-all 브랜치 간에 캐시를 공유하되 각 작업에 고유한 캐시를 사용하려면: cache: key: $CI_JOB_NAME 변수를 사용하여 작업의 캐시 정책 제어 # 히스토리 GitLab 16.1에서 도입 되었습니다. 가져오기 정책만 다른 작업의 중복을 줄이기 위해 CI/CD 변수 를 사용할 수 있습니다. 예를 들어: conditional-policy: rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH variables: POLICY: pull-push - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH variables: POLICY: pull stage: build cache: key: gems policy: $POLICY paths: - vendor/bundle script: - echo "This job pulls and pushes the cache depending on the branch" - echo "Downloading dependencies..." 이 예시에서 작업의 캐시 정책은: 기본 브랜치 변경에 대해 pull-push . 다른 브랜치 변경에 대해 pull . 종속성 캐싱 # 이 예시들은 프로그래밍 언어별로 일반적인 종속성을 캐싱하는 방법을 보여줍니다. Node.js # 프로젝트가 Node.js 종속성을 설치하기 위해 npm 을 사용하는 경우, 다음 예시는 모든 작업이 상속하도록 기본 cache 를 정의합니다. 기본적으로 npm은 홈 폴더( ~/.npm )에 캐시 데이터를 저장합니다. 그러나 프로젝트 디렉토리 외부의 항목은 캐싱할 수 없습니다 . 대신 npm이 ./.npm 을 사용하도록 하고 브랜