파이프라인 캐싱

  • 아티클

Azure DevOps Services

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

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

캐싱은 현재 CI 및 배포 작업에서 지원되지만 클래식 릴리스 작업은 지원되지 않습니다.

아티팩트 및 캐싱을 사용하는 경우

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

  • 한 작업에서 생성된 특정 파일을 가져와서 다른 작업과 공유해야 하는 경우 파이프라인 아티팩트(파이프라인 아티팩 트)를 사용합니다(이러한 다른 작업은 실패할 수 있습니다.)

  • 이전 실행에서 파일을 다시 사용하여 빌드 시간을 개선하려는 경우 파이프라인 캐싱 을 사용합니다(이러한 파일이 없으면 작업의 실행 기능에 영향을 주지 않음).

참고 항목

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

캐시 작업: 작동 방식

캐시 작업은 캐시 작업을 사용하여 파이프라인에 추가됩니다. 이 작업은 다른 작업과 마찬가지로 작동하며 작업의 섹션에 steps 추가됩니다.

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

작업의 모든 단계를 실행하고 성공적인 작업 상태 가정하면 건너뛰지 않은 각 "복원 캐시" 단계에 대해 특수한 "사후 작업: 캐시" 단계가 자동으로 추가되고 트리거됩니다. 이 단계에서는 캐시를 저장해야 합니다.

참고 항목

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

캐시 작업 구성

캐시 작업에는 키와 경로라는 두 가지 필수 인수가 있습니다.

  • path: 캐시할 폴더의 경로입니다. 절대 경로 또는 상대 경로일 수 있습니다. 상대 경로는 .에 대해 $(System.DefaultWorkingDirectory)확인됩니다.

참고 항목

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

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

  • 문자열:
    고정 값(예: 캐시 또는 도구 이름) 또는 환경 변수에서 가져온 값(예: 현재 OS 또는 현재 작업 이름)

  • 파일 경로:
    콘텐츠가 해시될 특정 파일의 경로입니다. 이 파일은 작업을 실행할 때 존재해야 합니다. "파일 경로처럼 보이는" 모든 키 세그먼트는 파일 경로처럼 처리됩니다. 특히 여기에는 을 포함하는 세그먼트가 .포함됩니다. 이 "파일"이 없으면 작업이 실패할 수 있습니다.

    팁

    경로와 유사한 문자열 세그먼트가 파일 경로처럼 처리되지 않도록 하려면 큰따옴표로 래핑합니다. 예를 들면 다음과 같습니다. "my.key" | $(Agent.OS) | key.file

  • 파일 패턴:
    하나 이상의 파일과 일치해야 하는 glob 스타일 wild카드 패턴의 쉼표로 구분된 목록입니다. 예시:

    • **/yarn.lock: 원본 디렉터리 아래의 모든 yarn.lock 파일
    • */asset.json, !bin/**: bin 디렉터리를 제외한 원본 디렉터리 아래의 디렉터리에 있는 모든 asset.json 파일

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

상대 파일 경로 또는 파일 패턴은 .에 대해 $(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 Required 필수 아니요
BSD Tar 아니요 아니요 Required
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 다른 해시yarn.lock를 생성한 캐시에 있는 old-yarn.lock 경우 복원 키는 부분 적중을 생성합니다. 첫 번째 복원 키가 누락된 경우 다음 복원 키를 yarn 사용하여 시작하는 키를 찾습니다 yarn. 접두사 적중의 경우 결과는 결과로 가장 최근에 만든 캐시 키를 생성합니다.

참고 항목

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

캐시 격리 및 보안

서로 다른 파이프라인과 다른 분기의 캐시 간에 격리를 보장하기 위해 모든 캐시는 범위라는 논리 컨테이너에 속합니다. 범위는 한 파이프라인의 작업이 다른 파이프라인의 캐시에 액세스할 수 없도록 하는 보안 경계를 제공하고 PR을 빌드하는 작업은 PR의 대상 분기(동일한 파이프라인)에 대한 캐시에 대한 읽기 액세스 권한을 가지지만 대상 분기의 범위에 캐시를 작성(만들기)할 수 없습니다.

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

CI, 수동 및 예약된 실행

범위 읽음 쓰기
원본 분기 예 예
기본 분기(기본 분기) 예 아니요

끌어오기 요청 실행

범위 읽음 쓰기
원본 분기 예 아니요
대상 분기 예 아니요
중간 분기(예: refs/pull/1/merge) 예 예
기본 분기(기본 분기) 예 아니요

끌어오기 요청 포크 실행

Branch 읽음 쓰기
대상 분기 예 아니요
중간 분기(예: refs/pull/1/merge) 예 예
기본 분기(기본 분기) 예 예

팁

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

캐시 복원에 대한 컨디셔닝

일부 시나리오에서는 캐시를 성공적으로 복원하면 다른 단계 집합이 실행되어야 합니다. 예를 들어 캐시가 복원된 경우 종속성을 설치하는 단계를 건너뛸 수 있습니다. 이 작업은 작업 입력을 cacheHitVar 사용하여 수행할 수 있습니다. 이 입력을 환경 변수의 이름으로 설정하면 캐시 적중이 있을 때, 복원 키 캐시 적중 inexact 시 변수가 설정 true 되고, 그렇지 않으면 변수가 설정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에서 사용하는 환경 변수를 재정 BUNDLE_PATH 의합니다.

예제:

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 필요에 따라 Ccache 실행 모드를 참조하세요PATH. 환경 변수를 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'))
  • key: (필수) - 캐시에 대한 고유 식별자입니다.
  • path: (필수) - 캐시하려는 폴더 또는 파일의 경로입니다.

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 를 실행하거나 파일에 추가 org.gradle.caching=true 합니다 gradle.properties .

예제:

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

예제:

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

프로젝트 파일 내에서 직접 NuGet 종속성을 관리하고 파일이 있는 packages.lock.json 경우 PackageReferences 환경 변수를 경로로 $(UserProfile) 설정하고 NUGET_PACKAGES 이 디렉터리를 캐싱하여 캐싱을 사용하도록 설정할 수 있습니다. 종속성을 잠그는 방법에 대한 자세한 내용은 프로젝트 파일의 패키지 참조를 참조하세요. 여러 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

Node.js/npm

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

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

예제:

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_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

알려진 문제 및 피드백

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

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: 조직의 개별 캐시 크기 또는 모든 캐시의 총 크기에 대한 제한은 없습니다.