속도 향상을 위한 디펜던시 캐시

워크플로우를 더 빠르고 효율적으로 만들기 위해, 디펜던시들과 자주 재사용하는 파일들의 캐시를 만들고 사용할 수 있습니다.

워크플로우 디펜던시 캐시에 관하여#

워크플로우는 같은 결과나 다운로드된 디펜던시들을 자주 재사용합니다. 예를들면 패키지와 디펜던시 관리 툴들 (Maven, Gradle, npm, and Yarn) 등은 다운로드된 디펜던시의 로컬 캐시를 갖고 있습니다.

깃허브 호스티드 러너에 있는 잡들은 깨끗한 가상환경에서 시작해야 하고 매번 디펜던시들을 다운로드 해야합니다. 이는 네트워크 사용(utilization) 증가와 길어지는 런타임, 비용 증가를 야기합니다. 이 파일들을 재생성하는데 걸리는 시간을 빠르게 하기 위해 자주쓰는 디펜던시들을 워크플로우에 캐싱할 수 있습니다.

민감한 정보를 퍼블릭 레포지토리에 캐싱하여 저장하는 것을 권장하지 않습니다. 레포지토리의 포크들은 배이스 브런치에 있는 캐시들에 대한 읽기 권한을 가지고 있습니다.

잡을 위한 디펜던시드릉ㄹ 캐싱하기 위해선 깃허브의 cache 액션을 쓸 필요가 있습니다. 그 액션은 유니크 키로 식별된 캐시를 리트라이브(retrievees)합니다. 더 자세한 내용은 actions/cache를 참조하세요.

아티팩트와 디펜던시 캐싱 비교#

아티팩트들과 캐싱은 비슷한데, 둘 다 깃허브에 파일을 저장하는 능력을 제공하기 때문입니다. 하지만 각각은 다른 용도와 서로 대체할 수 없는 용도로 제공됩니다.

잡이나 워크플로우의 실행 사이에 자주 바뀌지 않는 파일을 재사용하고 싶을 때 캐싱을 씁니다.
워크플로우가 끝나고 보기위한 잡에 의해 생성된 파일들을 저장하고 싶을 때 아티팩트를 씁니다.

캐시 액션 사용하기#

cache 액션은 제공된 key를 토대로 캐시를 복구하려고 시도합니다. 액션이 캐시를 찾으면 캐시된 파일을 구성한 path에 복원합니다.

매치되는 게 없으면, 성공적인 잡의 완료를 위해 새로운 캐시 엔트리를 만듭니다. 새로운 캐시는 사용자가 제공하는 key를 사용하고, path 디렉토리에 파일들은 포함하고 있습니다.

키가 존재하는 캐시와 일치하지 않으면, 사용되는 restore-keys의 리스트를 선택적으로 제공할 수 있습니다. 이는 다른 브랜치의 레포지토리에서 캐시를 복원할 때 유용한데, 왜냐하면 restore-keys는 캐시 키들과 부분적으로 맞을 수도 있기 때문입니다. 더 자세한 내용은 "Matching a cache"를 참고하십시오.

더 자세한 내용은, action/cache

캐시 액션을 위한 입력 파라미터#

key: 필수 키는 캐시를 저장할 때나 캐시를 검색할 때 생성됩니다. 변수 조합, 컨텍스트 값, 스태틱 문자열, 그리고 함수들이 될 수도 있습니다. 키는 최대 512 캐릭터의 길이를 가지며, 이를 초과할 경우 fail을 초래할 수도 있습니다.
path 필수 캐시되거나 복구되는 러너의 파일 경로입니다. 절대경로, 상대경로 둘 다 가능합니다. path의 입력값은 꼭 디렉토리여야합니다. path는 GITHUB-WORKSPACE 디렉토리 안에 반드시 위치해 있어야 합니다. 더 많은 정보는 "Github 액션의 가상환경들(https://help.github.com/en/github/automating-your-workflow-with-github-actions/virtual-environments-for-github-actions/#default-environment-variables)을 참고하세요.
restore-key: 선택 key에 대해 아무런 캐시도 찾지 못할 경우에 해당 캐시를 찾기위한 대체 키들의 정렬된 리스트.

캐시 액션을 위한 출력 파라미터#

cache-hit: 캐시 힛을 위해 true로 설정한다. 반대로 캐시 미스를 위해 false로 설정한다.

캐시 액션 사용 예제#

name: Caching with npm

on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

      - name: Cache node modules
        uses: actions/cache@v1
        with:
          path: node_modules
          key: ${{ runner.OS }}-build-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.OS }}-build-${{ env.cache-name }}-
            ${{ runner.OS }}-build-
            ${{ runner.OS }}-

      - name: Install Dependencies
        run: npm install

      - name: Build
        run: npm build

      - name: Test
        run: npm test

key가 존재하는 캐시와 매칭될때 캐시 힛이라 부른다. 그리고 액션은 path 디렉토리에 캐시된 파일들을 복원한다.

key가 존재하는 캐시와 매칭되지 않을 경우, 캐시 미스라 부른다. 그리고 잡이 성공적으로 완료되면 새로운 캐시가 만들어진다. 캐시 미스가 발생했을 땐, 액션은 restore-keys라는 대체 키들을 검색한다.

restore-keys를 제공한다면, cache 액션은 순차적으로 검색하여 restore-keys랑 매치되는 캐시를 순차적으로 검색해준다.

매치되는 게 있으면, 액션은 파일을 path 디렉토리에 복원합니다.
매치되는 게 없다면, 액션은 부분적으로 매치되는지에 대해 검색합니다. 부분적 매칭을 찾는다면 가장 최근의 캐시가 path 디렉토리로 복원됩니다.

캐시 액션이 완료되고 난 다음 잡의 워크플로우 스텝이 실행됩니다.
만약 잡이 성공적으로 완료했다면, 액션은 path 디렉토리의 내용으로 새로운 캐시를 생성하빈다.

하나 이상의 디렉토리에서 파일을 캐시하려면, cache 액션을 쓰는 스텝이 각 디렉토리마다 필요합니다. 한번 캐시를 생성하고 나면 존재하는 캐시의 내용은 바꿀 수 없지만, 새로운 키로 새로운 캐시를 생성할 수 있습니다.

캐시 키 생성을 위한 컨텍스트#

캐시 키는 깃허브에서 지원하는 컨텍스트, 함수, 리터럴, 그리고 연산자를 포함할 수 있습니다. 더 자세한 내용은 컨텍스트와 표현식 문법을 참고하세요.

key를 생성하기 위한 표현식은 디펜던시들이 바뀔 때마다 자동으로 새로운 캐시가 생성되게 해줍니다. 예를 들면, npm package-lock.json 파일의 해쉬를 계산하는 표현식을 사용함으로써 key를 생성할 수 있습니다.

npm-${{ hashFiles('pacakage-lock.json')}}

깃허브는 hash "package-lock.json" 표현식을 평가하여 최종키를 도출합니다.

npm-d5ea0750

캐시 매칭하기#

key에 해당하는 캐시가 없을 경우 복구키들의 리스트를 제공할 수 있습니다. cache 액션은 restore-keys에 대해 순차적으로 검색합니다. 키가 온전히 들어맞느 것이 없으면, 접두에 붙은(prefixed) 키들에 대해 복구키로 검색합니다. 다중의 부분적 매칭이 있다면, 액션은 가장 최근에 생성된 캐시를 반환합니다.

정렬된 다중의 복구키를 자세하거나 느슨하게 생성할 수 있습니다.

다중의 복구키 사용 예시#

restore-keys: |
  npm-foobar-${{ hashFiles('package-lock.json') }}
  npm-foobar-
  npm-

러너는 restore-keys를 푸는 표현식을 평가합니다.

restore-keys: |
  npm-foobar-d5ea0750
  npm-foobar-
  npm-

복구 키 npm-foobar-는 npm-foobar-로 시작하는 어떤 문자열과도 매치됩니다. 예를들면, npm-foobar-fd3052de와 npm-foobar-a9b253ff는 복구키와 매치됩니다. 이 중 가장 최근에 만들어진 캐시가 쓰일 것이지만요. 이 예시의 키들은 다음의 순서에 따라 검색이 이루어질겁니다.

npm-foobar-d5ea750은 특정 해쉬와 매칭된다.
npm-foobar- 가 npm-foobar를 접두어(prefixed)로 가진 키들과 매치된다.
npm- 은 npm-을 접두어로 가진 키들과 매치된다.

캐시 스코프#

캐시를 생성할 때, 워크플로우 실행의 브랜치를 가리키는 스코프 프로퍼티를 포함합니다. 당신은 어떤 브런치에서라도 만들어진 캐시를 복원할 수 있고, 포크된 레포지토리들의 베이스 브런치 또한 이에 포함됩니다. 스코프는 캐시 고립(isolation)과 보안을 논리적인 경계(logical boundary)를 워크플로우와 브랜치간에 만듦으로써 제공합니다.

캐시 액션은 현재 스코프(current scope, 워크플로우 실행을 포함하는 포함(contain)하는 브랜치)에서 key에 대한 캐시 히트와 restore-keys에 대해서 항상 검색합니다. 만약 현재 스코프에 히트가 없다면, 캐시 액션은 key와 restore-keys를 다음 스코프(부모나 업스트림 브랜치)에서 검색합니다.

검색 우선순위의 순서#

key: npm-feature-d5ea0750
restore-keys: |
  npm-feature-
  npm-

예를 들면, 풀 요청이 feature 브랜치(현재 스코프)를 포함하고, 목표가 default branch(master)였다면, key와 restore-keys를 다음 순서에 맞춰 검색합니다.

feature 브랜치 스코프 안의 키 npm-featured-5ea0750
feature 브랜치 스코프 안의 키 npm-featured-
feature 브랜치 스코프 안의 키 npm-
master 브랜치 스코프 안의 키 npm-featured-5ea0750
master 브랜치 스코프 안의 키 npm-5ea0750
master 브랜치 스코프 안의 키 npm

사용 제한 및 정책#

깃허브는 7일을 넘은 액세스하지 않은 캐시는 지웁니다. 또 다음의 조건에 부합한다면 원하는 만큼 많은 캐시 엔트리들을 저장할 수 있을 것입니다.

개별적인 파일이 400MB 이상이면 안됩니다. 400 - Bad Request
캐시 총 용량이 2GB 이상이면 안됩니다. 만약 그런다면 오류없이 저장은 되지만 2GB 이후로는 잘립니다.