파이프라인 캐싱

아티클
01/07/2025

Azure DevOps Services

파이프라인 캐싱은 한 실행의 출력 또는 다운로드한 종속성을 이후 실행에서 다시 사용할 수 있도록 하여 빌드 시간을 줄일 수 있으므로 동일한 파일을 다시 만들거나 다시 로드하는 비용을 줄이거나 방지할 수 있습니다. 캐싱은 각 실행이 시작될 때 동일한 종속성이 반복해서 다운로드되는 시나리오에서 특히 유용합니다. 이 프로세스는 종종 수백 또는 수천 개의 네트워크 호출을 포함하는 시간이 많이 소요되는 프로세스입니다.

캐시를 복원하고 저장하는 시간이 처음부터 다시 출력을 생성하는 시간보다 적으면 캐싱은 빌드 시간을 개선하는 데 효과적일 수 있습니다. 이 때문에 캐싱은 모든 시나리오에서 효과적이지 않을 수 있으며 실제로 빌드 시간에 부정적인 영향을 미칠 수 있습니다.

메모

클래식 릴리스 파이프라인에서는 파이프라인 캐싱이 지원되지 않습니다.

아티팩트와 캐싱 중 어느 것을 사용할지 결정하는 경우

파이프라인 캐싱 및 파이프라인 아티팩트가 유사한 함수를 수행할 있지만 다양한 시나리오를 위해 설계되었으며 서로 다른 용도로 사용하면 안 됩니다.

한 작업에서 생성된 특정 파일을 가져와서 다른 작업과 공유해야 하는 경우 파이프라인 아티팩트 사용합니다(이러한 다른 작업은 그렇지 않으면 실패할 수 있습니다).
이전 실행에서 파일을 다시 사용하여 빌드 시간을 개선하려는 경우 파이프라인 캐싱 사용합니다(이러한 파일이 없으면 작업의 실행 기능에 영향을 주지 않음).

메모

파이프라인 캐싱 및 파이프라인 아티팩트에서는 모든 계층(무료 및 유료)에 대해 무료입니다. 자세한 내용은 Artifacts 스토리지 사용량 참조하세요.

캐시 작업: 작동 방식

캐싱은 캐시 작업사용하여 파이프라인에 추가됩니다. 이 작업은 다른 작업처럼 작동하며 작업의 steps 섹션에 추가됩니다.

실행하는 동안 캐시 단계가 발견되면 태스크는 제공된 입력에 따라 캐시를 복원합니다. 캐시가 없으면 단계가 완료되고 작업의 다음 단계가 실행됩니다.

작업의 모든 단계가 실행된 후, 성공한 작업 상태를 가정할 때, 건너뛰지 않은 각 "캐시 복원" 단계에 대해 특수 "사후 작업: 캐시" 단계가 자동으로 추가되고 실행됩니다. 이 단계는 캐시을 저장하는 역할을 합니다.

메모

캐시는 변경할 수 없습니다. 즉, 캐시가 만들어지면 해당 콘텐츠는 변경되지 않습니다.

캐시 작업 구성

캐시 태스크키 및 경로두 가지 필수 인수가 있습니다.

경로: 캐시할 폴더의 경로입니다. 절대 경로 또는 상대 경로일 수 있습니다. 상대 경로는 $(System.DefaultWorkingDirectory)을 기준으로 해결됩니다.

메모

미리 정의된 변수를 사용하여 캐시하려는 폴더의 경로를 저장할 수 있지만 와일드카드는 지원되지 않습니다.

키: 복원하거나 저장하려는 캐시의 식별자로 설정해야 합니다. 키는 문자열 값, 파일 경로 또는 파일 패턴의 조합으로 구성되며 각 세그먼트는 | 문자로 구분됩니다.

문자열:
고정 값(예: 캐시 또는 도구 이름) 또는 환경 변수에서 가져온 값(예: 현재 OS 또는 현재 작업 이름)
파일 경로:
콘텐츠가 해시될 특정 파일의 경로입니다. 이 파일은 작업을 실행할 때 존재해야 합니다. 명심하십시오, "파일 경로처럼 보이는" 모든 키 세그먼트는 파일 경로처럼 처리됩니다. 특히 여기에는 .포함하는 세그먼트가 포함됩니다. 이 "파일"이 없으면 작업이 실패할 수 있습니다.

팁

경로와 유사한 문자열 세그먼트가 파일 경로처럼 처리되지 않도록 하려면 큰따옴표로 래핑합니다(예: "my.key" | $(Agent.OS) | key.file
파일 패턴:
하나 이상의 파일과 일치해야 하는 glob 스타일 와일드카드 패턴의 쉼표로 구분된 목록입니다. 예를 들어:
- **/yarn.lock: 소스 디렉터리 아래의 모든 yarn.lock 파일
- */asset.json, !bin/**: bin 디렉터리를 제외한 원본 디렉터리 아래의 디렉터리에 있는 모든 asset.json 파일

파일 경로 또는 파일 패턴으로 식별되는 파일의 콘텐츠는 동적 캐시 키를 생성하기 위해 해시됩니다. 이 기능은 프로젝트에 캐시되는 내용을 고유하게 식별하는 파일이 있는 경우에 유용합니다. 예를 들어 package-lock.json, yarn.lock, Gemfile.lock또는 Pipfile.lock 같은 파일은 모두 고유한 종속성 집합을 나타내므로 캐시 키에서 일반적으로 참조됩니다.

상대 파일 경로 또는 파일 패턴은 $(System.DefaultWorkingDirectory)를 기준으로 처리됩니다.

예제:

다음은 Yarn에서 설치한 종속성을 캐시하는 방법을 보여 주는 예제입니다.

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/s/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       "yarn" | "$(Agent.OS)"
       "yarn"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

이 예제에서 캐시 키에는 정적 문자열("yarn"), 이 캐시가 운영 체제별로 고유하기 때문에 작업이 실행 중인 OS, 캐시의 종속성 집합을 고유하게 식별하는 yarn.lock 파일의 해시의 세 부분이 포함됩니다.

작업이 추가된 후 첫 번째 실행에서 캐시 단계에서는 이 키로 식별된 캐시가 없으므로 "캐시 누락"을 보고합니다. 마지막 단계가 끝나면 $(Pipeline.Workspace)/s/.yarn 파일에서 캐시가 만들어지고 업로드됩니다. 다음 실행 시 캐시 단계에서는 "캐시 적중"을 보고하고 캐시의 내용을 다운로드하고 복원합니다.

checkout: self을(를) 사용할 때, 리포지토리가 $(Pipeline.Workspace)/s에 체크아웃되며, .yarn 폴더는 일반적으로 리포지토리 자체에 위치합니다.

메모

Pipeline.Workspace 모든 디렉터리를 만드는 파이프라인을 실행하는 에이전트의 로컬 경로입니다. 이 변수는 Agent.BuildDirectory와 같은 값을 가집니다.

.yarn가 있는 리포지토리를 가리키도록 하기 위해 checkout: self이 아닌 다른 항목을 사용하는 경우, 변수 YARN_CACHE_FOLDER를 업데이트해야 합니다.

키 복원

여러 개의 정확한 키 또는 키 접두사를 쿼리하려는 경우 restoreKeys을 사용할 수 있습니다. 이는 key 적중을 생성하지 않는 경우 다른 키로 대체되는 데 사용됩니다. 복원 키는 접두사로 키를 검색하고 가장 최근에 생성된 캐시 항목을 반환합니다. 이는 파이프라인이 정확한 일치 항목을 찾을 수 없지만 부분 캐시 적중을 대신 사용하려는 경우에 유용합니다. 여러 복원 키를 삽입하려면 새 줄을 사용하여 복원 키를 표시하여 구분합니다(자세한 내용은 예제 참조). 복원 키를 시험하는 순서는 위에서 아래로 진행됩니다.

자체 호스팅된 에이전트의 필수 소프트웨어

보관 소프트웨어/플랫폼	Windows	Linux	Mac
GNU Tar	필수	필수	아니요
BSD Tar	아니요	아니요	필수
7-Zip	권장	아니요	아니요

위의 실행 파일은 PATH 환경 변수에 나열된 폴더에 있어야 합니다. 호스팅된 에이전트는 포함된 소프트웨어와 함께 제공되며 자체 호스팅 에이전트에만 적용됩니다.

예제:

Yarn에서 복원 키를 사용하는 방법의 예는 다음과 같습니다.

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

이 예제에서 캐시 태스크는 키가 캐시에 있는지 확인하려고 시도합니다. 캐시에 키가 없으면 yarn | $(Agent.OS)첫 번째 복원 키를 사용하려고 합니다. 이렇게 하면 해당 키와 정확히 일치하거나 해당 키를 접두사로 사용하는 모든 키를 검색하려고 합니다. 다른 yarn.lock 해시 세그먼트가 있는 경우 접두사 적중이 발생할 수 있습니다. 예를 들어, 캐시에서 키 yarn | $(Agent.OS) | old-yarn.lock가 있고, old-yarn.lock이 yarn.lock와 다른 해시를 생성하는 경우, 복원 키는 부분 적중을 일으킬 수 있습니다. 첫 번째 복원 키가 실패하면, 다음 복원 키 yarn를 사용하여 yarn로 시작하는 키를 찾으려고 시도합니다. 접두사가 일치하는 경우, 결과로 가장 최근에 생성된 캐시 키를 반환합니다.

메모

파이프라인에는 하나 이상의 캐싱 작업이 있을 수 있습니다. 캐싱 스토리지 용량에는 제한이 없으며 동일한 파이프라인의 작업 및 태스크가 동일한 캐시에 액세스하고 공유할 수 있습니다.

캐시 격리 및 보안

서로 다른 파이프라인 및 분기의 캐시 간 격리를 보장하기 위해, 모든 캐시는 '범위'라는 논리적 컨테이너에 속합니다. 범위는 보안 경계로서 다음을 보장합니다.

한 파이프라인의 작업은 다른 파이프라인의 캐시에 접근할 수 없으며
PR을 빌드하는 작업은 PR의 대상 분기(동일한 파이프라인)에 대한 캐시에 대한 읽기 액세스 권한을 가지지만 대상 분기의 범위에 캐시를 작성(만들기)할 수는 없습니다.

실행하는 동안 캐시 단계가 발견되면 키로 식별되는 캐시가 서버에서 요청됩니다. 그런 다음 서버는 작업에 표시되는 범위에서 이 키가 있는 캐시를 찾고 캐시(사용 가능한 경우)를 반환합니다. 캐시 저장 시(작업 종료 시) 캐시는 파이프라인 및 분기를 나타내는 범위에 기록됩니다. 자세한 내용은 아래를 참조하세요.

CI, 수동 및 예약된 실행

범위	읽다	쓰다
소스 브랜치	예	예
`main` 분기	예	아니요
`master` 분기	예	아니요

끌어오기 요청 실행

범위	읽다	쓰다
원본 분기	예	아니요
대상 브랜치	예	아니요
중간 분기(예: `refs/pull/1/merge`)	예	예
`main` 분기	예	아니요
`master` 분기	예	아니요

풀 리퀘스트 포크 실행

가지	읽다	쓰다
대상 브랜치	예	아니요
중간 분기(예: `refs/pull/1/merge`)	예	예
`main` 브랜치	예	아니요
`master` 브랜치	예	아니요

팁

캐시는 이미 프로젝트, 파이프라인 및 분기로 범위가 지정되어 있으므로 캐시 키에 프로젝트, 파이프라인 또는 분기 식별자를 포함할 필요가 없습니다.

캐시 복원에 대한 조건 설정

일부 시나리오에서는 캐시를 성공적으로 복원하면 다른 단계 집합이 실행되어야 합니다. 예를 들어 캐시가 복원된 경우 종속성을 설치하는 단계를 건너뛸 수 있습니다. 이것은 cacheHitVar 작업 입력을 사용함으로써 가능합니다. 이 입력을 환경 변수의 이름으로 설정하면, 캐시 적중 시 변수는 true로 설정되고, 복원 키 캐시 적중 시에는 inexact로 설정됩니다. 그 외의 경우에는 false로 설정됩니다. 그런 다음 이 변수는 단계 조건 또는 스크립트 내에서 참조할 수 있습니다.

다음 예제에서는 캐시가 복원될 때 install-deps.sh 단계를 건너뜁습니다.

steps:
- task: Cache@2
  inputs:
    key: mykey | mylockfile
    restoreKeys: mykey
    path: $(Pipeline.Workspace)/mycache
    cacheHitVar: CACHE_RESTORED

- script: install-deps.sh
  condition: ne(variables.CACHE_RESTORED, 'true')

- script: build.sh

번들러(Bundler)

Bundler를 사용하는 Ruby 프로젝트의 경우 Bundler가 Gems를 찾을 경로를 설정하기 위해 Bundler에서 사용하는 환경 변수를 재정의합니다.

예제:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    path: $(BUNDLE_PATH)
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems

Ccache(C/C++)

Ccache C/C++에 대한 컴파일러 캐시입니다. 파이프라인에서 Ccache를 사용하려면 Ccache이 설치되어 있는지 확인하고, 필요하다면 PATH에 추가할 수 있습니다(Ccache 실행 모드참조). CCACHE_DIR 환경 변수를 $(Pipeline.Workspace) 아래의 경로로 설정하고 이 디렉터리를 캐시합니다.

예제:

variables:
  CCACHE_DIR: $(Pipeline.Workspace)/ccache

steps:
- bash: |
    sudo apt-get install ccache -y    
    echo "##vso[task.prependpath]/usr/lib/ccache"
  displayName: Install ccache and update PATH to use linked versions of gcc, cc, etc

- task: Cache@2
  displayName: Ccache caching
  inputs:
    key: 'ccache | "$(Agent.OS)" | $(Build.SourceVersion)'
    path: $(CCACHE_DIR)
    restoreKeys: | 
      ccache | "$(Agent.OS)"

자세한 내용은 Ccache 구성 설정 참조하세요.

Docker 이미지

Docker 이미지를 캐싱하면 파이프라인을 실행하는 데 걸리는 시간이 크게 줄어듭니다.

variables:
  repository: 'myDockerImage'
  dockerfilePath: '$(Build.SourcesDirectory)/app/Dockerfile'
  tag: '$(Build.BuildId)'

pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: Cache@2
    displayName: Cache task
    inputs:
      key: 'docker | "$(Agent.OS)" | cache'
      path: $(Pipeline.Workspace)/docker
      cacheHitVar: CACHE_RESTORED                #Variable to set to 'true' when the cache is restored
    
  - script: |
      docker load -i $(Pipeline.Workspace)/docker/cache.tar
    displayName: Docker restore
    condition: and(not(canceled()), eq(variables.CACHE_RESTORED, 'true'))

  - task: Docker@2
    displayName: 'Build Docker'
    inputs:
      command: 'build'
      repository: '$(repository)'
      dockerfile: '$(dockerfilePath)'
      tags: |
        '$(tag)'

  - script: |
      mkdir -p $(Pipeline.Workspace)/docker
      docker save -o $(Pipeline.Workspace)/docker/cache.tar $(repository):$(tag)
    displayName: Docker save
    condition: and(not(canceled()), not(failed()), ne(variables.CACHE_RESTORED, 'true'))

키: (필수) - 캐시에 대한 고유 식별자입니다.
경로: (필수) - 캐시하려는 폴더 또는 파일의 경로입니다.

골랑어(Golang)

Golang 프로젝트의 경우 go.mod 파일에서 다운로드할 패키지를 지정할 수 있습니다. GOCACHE 변수가 아직 설정되지 않은 경우 캐시를 다운로드할 위치로 설정합니다.

예제:

variables:
  GO_CACHE_DIR: $(Pipeline.Workspace)/.cache/go-build/

steps:
- task: Cache@2
  inputs:
    key: 'go | "$(Agent.OS)" | go.mod'
    restoreKeys: | 
      go | "$(Agent.OS)"
    path: $(GO_CACHE_DIR)
  displayName: Cache GO packages

Gradle

Gradle의 기본 제공 캐싱 지원 사용하면 빌드 시간에 큰 영향을 미칠 수 있습니다. 빌드 캐시를 사용하도록 설정하려면 GRADLE_USER_HOME 환경 변수를 $(Pipeline.Workspace) 아래의 경로로 설정하고 --build-cache 사용하여 빌드를 실행하거나 gradle.properties 파일에 org.gradle.caching=true 추가합니다.

예제:

variables:
  GRADLE_USER_HOME: $(Pipeline.Workspace)/.gradle

steps:
- task: Cache@2
  inputs:
    key: 'gradle | "$(Agent.OS)" | **/build.gradle.kts' # Swap build.gradle.kts for build.gradle when using Groovy
    restoreKeys: |
      gradle | "$(Agent.OS)"
      gradle
    path: $(GRADLE_USER_HOME)
  displayName: Configure gradle caching

- task: Gradle@2
  inputs:
    gradleWrapperFile: 'gradlew'
    tasks: 'build'
    options: '--build-cache'
  displayName: Build

- script: |   
    # stop the Gradle daemon to ensure no files are left open (impacting the save cache operation later)
    ./gradlew --stop    
  displayName: Gradlew stop

restoreKeys: 기본 키가 실패하는 경우 대체 키(선택 사항)

메모

캐시는 불변이며, 특정 범위(브랜치)에 대해 특정 키로 캐시가 생성되면, 해당 캐시는 업데이트할 수 없습니다. 즉, 키가 고정 값인 경우 캐시의 내용이 변경된 경우에도 동일한 분기에 대한 모든 후속 빌드에서 캐시를 업데이트할 수 없습니다. 고정 키 값을 사용하려면 restoreKeys 인수를 대체 옵션으로 사용해야 합니다.

Maven

Maven에는 다운로드 및 빌드된 아티팩트를 저장하는 로컬 리포지토리가 있습니다. 사용하도록 설정하려면 maven.repo.local 옵션을 $(Pipeline.Workspace) 아래의 경로로 설정하고 이 폴더를 캐시합니다.

예제:

variables:
  MAVEN_CACHE_FOLDER: $(Pipeline.Workspace)/.m2/repository
  MAVEN_OPTS: '-Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)'

steps:
- task: Cache@2
  inputs:
    key: 'maven | "$(Agent.OS)" | **/pom.xml'
    restoreKeys: |
      maven | "$(Agent.OS)"
      maven
    path: $(MAVEN_CACHE_FOLDER)
  displayName: Cache Maven local repo

- script: mvn install -B -e

Maven 작업사용하는 경우 그렇지 않으면 덮어쓰여지므로 MAVEN_OPTS 변수도 전달해야 합니다.

- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    mavenOptions: '-Xmx3072m $(MAVEN_OPTS)'

.NET/NuGet

PackageReferences을 사용하여 프로젝트 파일 내에서 NuGet 종속성을 직접 관리하고, packages.lock.json 파일이 있는 경우, NUGET_PACKAGES 환경 변수를 $(UserProfile) 아래의 경로로 설정하고 이 디렉터리를 캐시함으로써 캐싱을 활성화할 수 있습니다. 종속성을 잠그는 방법에 대한 자세한 내용은 프로젝트 파일 패키지 참조를 참조하세요. 여러 packages.lock.json사용하려는 경우에도 변경하지 않고 다음 예제를 사용할 수 있습니다. 모든 packages.lock.json 파일의 콘텐츠가 해시되고 파일 중 하나가 변경되면 새 캐시 키가 생성됩니다.

예제:

variables:
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

steps:
- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | $(Build.SourcesDirectory)/**/packages.lock.json'
    restoreKeys: |
       nuget | "$(Agent.OS)"
       nuget
    path: $(NUGET_PACKAGES)
  displayName: Cache NuGet packages

이 방법은 프로젝트에서 packages.lock.json 사용하여 패키지 버전을 잠그는 경우에도 .NET Core 프로젝트에 유효합니다. Csproj 파일에서 RestorePackagesWithLockFile을 True으로 설정하거나 다음 명령(dotnet restore --use-lock-file)을 사용하여 사용할 수 있습니다.

Node.js/npm

Node.js 프로젝트에서 캐싱을 사용하도록 설정하는 방법에는 여러 가지가 있지만 npm의 공유 캐시 디렉터리캐시하는 것이 좋습니다. 이 디렉터리 npm에서 관리 하 고 모든 다운로드 된 모듈의 캐시 된 버전을 포함 합니다. 설치하는 동안 npm은 공용 npm 레지스트리 또는 프라이빗 레지스트리에 대한 네트워크 호출을 줄이거나 제거할 수 있는 모듈에 대해 이 디렉터리를 먼저 확인합니다(기본적으로).

npm의 공유 캐시 디렉터리에 대한 기본 경로는모든 플랫폼에서 동일하지 않으므로 환경 변수를 아래의 경로로 재정의하는 것이 좋습니다. 이렇게 하면 컨테이너 및 비컨테이너 작업에서 캐시에 액세스할 수 있습니다.

예제:

variables:
  npm_config_cache: $(Pipeline.Workspace)/.npm

steps:
- task: Cache@2
  inputs:
    key: 'npm | "$(Agent.OS)" | package-lock.json'
    restoreKeys: |
       npm | "$(Agent.OS)"
    path: $(npm_config_cache)
  displayName: Cache npm

- script: npm ci

프로젝트에 package-lock.json 파일이 없는 경우 대신 캐시 키 입력에서 package.json 파일을 참조합니다.

팁

npm ci 일관되고 반복 가능한 모듈 집합이 사용되도록 node_modules 폴더를 삭제하므로 npm ci호출할 때 node_modules 캐싱하지 않아야 합니다.

Node.js/Yarn

npm과 마찬가지로 Yarn과 함께 설치된 패키지를 캐시하는 방법에는 여러 가지가 있습니다. Yarn의 공유 캐시 폴더캐시하는 것이 좋습니다. 이 디렉터리에는 Yarn에서 관리되며 다운로드한 모든 패키지의 캐시된 버전이 포함되어 있습니다. 설치하는 동안 Yarn은 공용 또는 프라이빗 레지스트리에 대한 네트워크 호출을 줄이거나 제거할 수 있는 모듈에 대해 이 디렉터리를 먼저 확인합니다(기본적으로).

예제:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: 'yarn | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

Python/Anaconda

Anaconda 환경을 사용하여 파이프라인 캐싱을 설정합니다.

예시

variables:
  CONDA_CACHE_DIR: /usr/share/miniconda/envs

# Add conda to system path
steps:
- script: echo "##vso[task.prependpath]$CONDA/bin"
  displayName: Add conda to PATH

- bash: |
    sudo chown -R $(whoami):$(id -ng) $(CONDA_CACHE_DIR)
  displayName: Fix CONDA_CACHE_DIR directory permissions

- task: Cache@2
  displayName: Use cached Anaconda environment
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA_CACHE_DIR)
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create Anaconda environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

Windows

- task: Cache@2
  displayName: Cache Anaconda
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA)/envs
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

PHP/Composer

PHP 프로젝트에서 Composer를 사용할 경우, Composer에서 사용하는 COMPOSER_CACHE_DIR환경 변수를 재정의합니다.

예제:

variables:
  COMPOSER_CACHE_DIR: $(Pipeline.Workspace)/.composer

steps:
- task: Cache@2
  inputs:
    key: 'composer | "$(Agent.OS)" | composer.lock'
    restoreKeys: |
      composer | "$(Agent.OS)"
      composer
    path: $(COMPOSER_CACHE_DIR)
  displayName: Cache composer

- script: composer install

알려진 문제 및 피드백

파이프라인에 대한 캐싱을 설정하는 데 문제가 발생하는 경우 리포지토리에서 열린 문제 목록을 확인합니다. 문제가 나열되지 않으면 새을 만들고 시나리오에 필요한 정보를 제공하십시오.

Q&A

Q: 캐시를 지울 수 있나요?

A: 캐시 지우기는 현재 지원되지 않습니다. 그러나 기존 캐시 키에 문자열 리터럴(예: version2)을 추가하여 기존 캐시에서 적중을 방지하는 방식으로 키를 변경할 수 있습니다. 예를 들어 다음 캐시 키를 다음과 같이 변경하세요.

key: 'yarn | "$(Agent.OS)" | yarn.lock'

이에:

key: 'version2 | yarn | "$(Agent.OS)" | yarn.lock'

Q: 캐시는 언제 만료되나요?

A: 7일 동안 활동이 없으면 캐시가 만료됩니다.

Q: 캐시는 언제 업로드되나요?

A: 파이프라인의 마지막 단계가 완료되면 path 캐시에서 캐시가 생성되어 업로드됩니다. 자세한 내용은 예제 참조하세요.

Q: 캐시 크기에 제한이 있나요?

A: 조직의 개별 캐시 크기 또는 모든 캐시의 총 크기에 대한 제한은 없습니다.

다음을 통해 공유