Cache dependencies in GitLab CI/CD · Gitlab 中文文檔

# Cache dependencies in GitLab CI/CD > 原文：[https://docs.gitlab.com/ee/ci/caching/](https://docs.gitlab.com/ee/ci/caching/) * [Cache vs artifacts](#cache-vs-artifacts) * [Good caching practices](#good-caching-practices) * [Sharing caches across the same branch](#sharing-caches-across-the-same-branch) * [Sharing caches across different branches](#sharing-caches-across-different-branches) * [Disabling cache on specific jobs](#disabling-cache-on-specific-jobs) * [Inherit global config, but override specific settings per job](#inherit-global-config-but-override-specific-settings-per-job) * [Common use cases](#common-use-cases) * [Caching Node.js dependencies](#caching-nodejs-dependencies) * [Caching PHP dependencies](#caching-php-dependencies) * [Caching Python dependencies](#caching-python-dependencies) * [Caching Ruby dependencies](#caching-ruby-dependencies) * [Caching Go dependencies](#caching-go-dependencies) * [Availability of the cache](#availability-of-the-cache) * [Where the caches are stored](#where-the-caches-are-stored) * [How archiving and extracting works](#how-archiving-and-extracting-works) * [Cache mismatch](#cache-mismatch) * [Examples](#examples) * [Clearing the cache](#clearing-the-cache) * [Clearing the cache by changing `cache:key`](#clearing-the-cache-by-changing-cachekey) * [Clearing the cache manually](#clearing-the-cache-manually) # Cache dependencies in GitLab CI/CD[](#cache-dependencies-in-gitlab-cicd "Permalink") GitLab CI / CD 提供了一種緩存機制，可用于在作業運行時節省時間. 緩存是指通過重用先前作業的相同內容來加快執行作業的時間. 當您開發依賴于在構建期間通過 Internet 獲取的其他庫的軟件時，此功能特別有用. 如果啟用了緩存，則默認情況下從 GitLab 9.0 開始，它在項目級別的管道和作業之間共享. 緩存不跨項目共享. 確保您閱讀了[`cache`參考](../yaml/README.html#cache)以了解`.gitlab-ci.yml`定義. ## Cache vs artifacts[](#cache-vs-artifacts "Permalink") **注意：**如果您使用緩存和工件在作業中存儲相同的路徑時要小心，因為在覆蓋**工件**和內容**之前** ，將**還原緩存** . 不要使用緩存在階段之間傳遞工件，因為緩存旨在存儲編譯項目所需的運行時依賴項： * `cache`: **用于存儲項目依賴項** 緩存用于通過存儲下載的依賴項來加快后續作業在給定**管道中的**運行速度，這樣就不必再次從 Internet 上獲取它們（例如 npm 軟件包，Go 供應商軟件包等）.配置為在階段之間傳遞中間構建結果，則應該使用工件來完成. * `artifacts`: **用于在階段之間傳遞的階段結果.** 工件是由作業生成的文件，可以存儲并上載，然后可以在**同一管道的**后續階段中由作業獲取和使用. 換句話說， [您不能在階段 1 的 job-A 中創建工件，然后在階段 1 的 job-B 中使用此工件](https://gitlab.com/gitlab-org/gitlab/-/issues/25837) . 此數據在不同的管道中將不可用，但可以從 UI 下載. `artifacts`的名稱聽起來像是僅在工作之外有用，例如用于下載最終圖像，但是人工制品也可以在管道的后期階段使用. 因此，如果通過下載所有必需的模塊來構建應用程序，則可能需要將它們聲明為工件，以便后續階段可以使用它們. 有一些優化措施，例如聲明[到期時間，](../yaml/README.html#artifactsexpire_in)這樣您就不會將工件保留太長時間，或者使用[依賴項](../yaml/README.html#dependencies)來控制哪些作業會獲取工件. Caches: * 如果未全局定義或未按作業定義（使用`cache:` ：），則禁用該功能. * 如果全局啟用，則可用于`.gitlab-ci.yml`所有作業. * 可以由創建緩存的同一作業在后續管道中使用（如果未全局定義）. * 如果[啟用了分布式緩存](https://docs.gitlab.com/runner/configuration/autoscale.html) ，則將它們存儲在 Runner 安裝的位置**并**上傳到 S3. * 如果按作業定義，則使用： * 通過后續管道中的相同作業. * 如果它們具有相同的依賴關系，則由同一管道中的后續作業組成. Artifacts: * 如果未按作業定義（使用`artifacts:` ：），則將其禁用. * 只能針對每個作業啟用，不能全局啟用. * 在管道中創建，并且可以被當前活動管道的后續作業使用. * 始終上傳到 GitLab（稱為協調器）. * 可以具有用于控制磁盤使用量的到期值（默認為 30 天）. **注意：**工件和緩存均定義了相對于項目目錄的路徑，并且無法鏈接到其外部的文件. ## Good caching practices[](#good-caching-practices "Permalink") We have the cache from the perspective of the developers (who consume a cache within the job) and the cache from the perspective of the Runner. Depending on which type of Runner you are using, cache can act differently. 從開發人員的角度來看，要確保高速緩存的最大可用性，在作業中聲明`cache` ，請使用以下一項或多項： * [為跑步者](../runners/README.html#use-tags-to-limit-the-number-of-jobs-using-the-runner)添加標簽，并在共享其緩存的作業上使用標簽. * [使用](../runners/README.html#prevent-a-specific-runner-from-being-enabled-for-other-projects)僅適用于特定項目的[粘性運行器](../runners/README.html#prevent-a-specific-runner-from-being-enabled-for-other-projects) . * [使用](../yaml/README.html#cachekey)適合您的工作流[的`key`](../yaml/README.html#cachekey) （例如，每個分支上的不同緩存）. 為此，您可以利用[CI / CD 預定義變量](../variables/README.html#predefined-environment-variables) . **提示：**在管道中使用相同的 Runner 是在一個階段或管道中緩存文件，并以有保證的方式將該緩存傳遞到后續階段或管道的最簡單，最有效的方法. 從 Runner 的角度來看，為了使緩存有效運行，必須滿足以下條件之一： * 為您的所有工作使用一個賽跑者. * 使用多個使用[分布式緩存的](https://docs.gitlab.com/runner/configuration/autoscale.html) Runner（無論是否處于自動縮放模式），這些[緩存](https://docs.gitlab.com/runner/configuration/autoscale.html)將緩存存儲在 S3 存儲桶中（例如 GitLab.com 上的共享 Runner）. * 使用具有相同體系結構的多個運行程序（不在自動伸縮模式下）共享公共網絡安裝目錄（使用 NFS 或類似方式），以存儲緩存. **提示：**了解[緩存](#availability-of-the-cache)的[可用性，](#availability-of-the-cache)以了解有關內部的更多信息，并更好地了解緩存的工作方式. ### Sharing caches across the same branch[](#sharing-caches-across-the-same-branch "Permalink") 使用`key: ${CI_COMMIT_REF_SLUG}`定義一個緩存，以便每個分支的作業始終使用相同的緩存： ``` cache: key: ${CI_COMMIT_REF_SLUG} ``` 盡管這似乎可以防止意外覆蓋緩存，但是這意味著合并請求的第一個流水線很慢，這可能會給開發人員帶來糟糕的體驗. 下次將新提交推送到分支時，將重新使用緩存. To enable per-job and per-branch caching: ``` cache: key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG" ``` 要啟用每個分支和每個階段的緩存： ``` cache: key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG" ``` ### Sharing caches across different branches[](#sharing-caches-across-different-branches "Permalink") 如果要緩存的文件需要在所有分支和所有作業之間共享，則可以對所有這些文件使用相同的密鑰： ``` cache: key: one-key-to-rule-them-all ``` 要在分支之間共享相同的緩存，但按作業將它們分開： ``` cache: key: ${CI_JOB_NAME} ``` ### Disabling cache on specific jobs[](#disabling-cache-on-specific-jobs "Permalink") 如果已全局定義了緩存，則意味著每個作業將使用相同的定義. 您可以按工作覆蓋此行為，如果要完全禁用它，請使用空哈希： ``` job: cache: {} ``` ### Inherit global config, but override specific settings per job[](#inherit-global-config-but-override-specific-settings-per-job "Permalink") 您可以使用[定位符](../yaml/README.html#anchors)覆蓋緩存設置，而無需覆蓋全局緩存. 例如，如果要覆蓋一項作業的`policy` ： ``` cache: &global_cache key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ - public/ - vendor/ policy: pull-push job: cache: # inherit all global cache settings <<: *global_cache # override the policy policy: pull ``` 要進行更精細的調整，還請閱讀有關[`cache: policy`](../yaml/README.html#cachepolicy) . ## Common use cases[](#common-use-cases "Permalink") 緩存最常見的用例是在后續作業之間保留內容，以用于諸如依賴項和常用庫（Node.js 包，PHP 包，rubygems，Python 庫等）之類的東西，因此不必從公共互聯網重新獲取. **注意：**有關更多示例，請查看我們的[GitLab CI / CD 模板](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates) . ### Caching Node.js dependencies[](#caching-nodejs-dependencies "Permalink") 假設您的項目正在使用[npm](https://s0www0npmjs0com.icopy.site/)安裝 Node.js 依賴項，下面的示例將全局定義`cache` ，以便所有作業都繼承它. 默認情況下，npm 將緩存數據存儲在主文件夾`~/.npm`但是由于[您無法緩存項目目錄之外的內容](../yaml/README.html#cachepaths) ，因此我們告訴 npm 使用`./.npm` ，它按分支緩存： ``` # # https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates/Nodejs.gitlab-ci.yml # image: node:latest # Cache modules in between jobs cache: key: ${CI_COMMIT_REF_SLUG} paths: - .npm/ before_script: - npm ci --cache .npm --prefer-offline test_async: script: - node ./specs/start.js ./specs/async.spec.js ``` ### Caching PHP dependencies[](#caching-php-dependencies "Permalink") 假設您的項目正在使用[Composer](https://s0getcomposer0org.icopy.site/)安裝 PHP 依賴項，下面的示例將全局定義`cache` ，以便所有作業都繼承它. PHP 庫模塊安裝在`vendor/`并按分支緩存： ``` # # https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates/PHP.gitlab-ci.yml # image: php:7.2 # Cache libraries in between jobs cache: key: ${CI_COMMIT_REF_SLUG} paths: - vendor/ before_script: # Install and run Composer - curl --show-error --silent https://getcomposer.org/installer | php - php composer.phar install test: script: - vendor/bin/phpunit --configuration phpunit.xml --coverage-text --colors=never ``` ### Caching Python dependencies[](#caching-python-dependencies "Permalink") 假設您的項目正在使用[pip](https://pip.pypa.io/en/stable/)安裝 Python 依賴項，以下示例將全局定義`cache` ，以便所有作業都繼承它. Python 庫安裝在`venv/`下的虛擬環境中，pip 的緩存在`.cache/pip/`下定義，并且兩者均按分支緩存： ``` # # https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml # image: python:latest # Change pip's cache directory to be inside the project directory since we can # only cache local items. variables: PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip" # Pip's cache doesn't store the python packages # https://pip.pypa.io/en/stable/reference/pip_install/#caching # # If you want to also cache the installed packages, you have to install # them in a virtualenv and cache it as well. cache: paths: - .cache/pip - venv/ before_script: - python -V # Print out python version for debugging - pip install virtualenv - virtualenv venv - source venv/bin/activate test: script: - python setup.py test - pip install flake8 - flake8 . ``` ### Caching Ruby dependencies[](#caching-ruby-dependencies "Permalink") 假設您的項目正在使用[Bundler](https://bundler.io)安裝 gem 依賴項，以下示例將全局定義`cache` ，以便所有作業都繼承它. 寶石安裝在`vendor/ruby/`并按分支緩存： ``` # # https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml # image: ruby:2.6 # Cache gems in between builds cache: key: ${CI_COMMIT_REF_SLUG} paths: - vendor/ruby before_script: - ruby -v # Print out ruby version for debugging - bundle install -j $(nproc) --path vendor/ruby # Install dependencies into ./vendor/ruby rspec: script: - rspec spec ``` ### Caching Go dependencies[](#caching-go-dependencies "Permalink") 假設您的項目正在使用[Go Modules](https://github.com/golang/go/wiki/Modules)安裝 Go 依賴項，以下示例在`go-cache`模板中定義了`cache` ，任何作業都可以擴展. Go 模塊安裝在`${GOPATH}/pkg/mod/` ，并為所有`go`項目緩存： ``` .go-cache: variables: GOPATH: $CI_PROJECT_DIR/.go before_script: - mkdir -p .go cache: paths: - .go/pkg/mod/ test: image: golang:1.13 extends: .go-cache script: - go test ./... -v -short ``` ## Availability of the cache[](#availability-of-the-cache "Permalink") 緩存是一種優化，但不能保證始終有效，因此您需要準備好在需要它們的每個作業中重新生成所有緩存的文件. 假設您已根據工作流程[在`.gitlab-ci.yml`](../yaml/README.html#cache)正確[定義了`cache`](../yaml/README.html#cache) ，則緩存的可用性最終取決于 Runner 的配置方式（執行程序類型以及是否使用不同的 Runner 在作業之間傳遞緩存）. ### Where the caches are stored[](#where-the-caches-are-stored "Permalink") 由于亞軍是一個負責存儲的緩存，這是必須要知道它的存儲**位置** . 在`.gitlab-ci.yml`中的作業下定義的所有緩存路徑都存儲在單個`cache.zip`文件中，并存儲在 Runner 的配置緩存位置中. 默認情況下，它們存儲在本地安裝了 Runner 的計算機中，具體取決于執行程序的類型. | GitLab Runner 執行器 | 緩存的默認路徑 | | --- | --- | | [Shell](https://docs.gitlab.com/runner/executors/shell.html) | 在本地，存儲在`gitlab-runner`用戶的主目錄下： `/home/gitlab-runner/cache/<user>/<project>/<cache-key>/cache.zip` home/ `gitlab-runner` user>/< `gitlab-runner` < `gitlab-runner` `/home/gitlab-runner/cache/<user>/<project>/<cache-key>/cache.zip` . | | [Docker](https://docs.gitlab.com/runner/executors/docker.html) | 在本地存儲在[Docker 卷下](https://docs.gitlab.com/runner/executors/docker.html) ：/ `/var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip` [docker / volumes / <卷](https://docs.gitlab.com/runner/executors/docker.html) `/var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip` _ `/var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip` . | | [Docker 機器](https://docs.gitlab.com/runner/executors/docker_machine.html) （自動縮放賽跑者） | 行為與 Docker 執行器相同. | ### How archiving and extracting works[](#how-archiving-and-extracting-works "Permalink") 在最簡單的情況下，請考慮僅使用一臺安裝了 Runner 的計算機，并且項目的所有作業都在同一主機上運行. 讓我們看下面兩個屬于兩個連續階段的作業的示例： ``` stages: - build - test before_script: - echo "Hello" job A: stage: build script: - mkdir vendor/ - echo "build" > vendor/hello.txt cache: key: build-cache paths: - vendor/ after_script: - echo "World" job B: stage: test script: - cat vendor/hello.txt cache: key: build-cache ``` 這是幕后發生的事情： 1. 管道開始. 2. `job A` runs. 3. 執行`before_script` . 4. `script`已執行. 5. `after_script`被執行. 6. `cache`運行，并且`vendor/`目錄被壓縮到`cache.zip` . 然后根據[Runner 的設置](#where-the-caches-are-stored)和`cache: key`將該文件保存在目錄中. 7. `job B` runs. 8. 提取緩存（如果找到）. 9. 執行`before_script` . 10. `script`已執行. 11. 管道完成. 通過在單臺計算機上使用單個 Runner，就不會出現`job B`可能在不同于`job A`的 Runner 上執行的問題，從而保證了各個階段之間的緩存. 僅當構建在同一 Runner /機器上從階段`build`到`test` ，此方法才有效，否則，您[可能沒有可用的緩存](#cache-mismatch) . 在緩存過程中，還需要考慮以下幾點： * 如果具有其他緩存配置的某些其他作業已將其緩存保存在同一 zip 文件中，則它將被覆蓋. 如果使用了基于 S3 的共享緩存，則還會根據緩存密鑰將文件另外上傳到 S3 到對象. 因此，路徑不同但緩存鍵相同的兩個作業將覆蓋其緩存. * 從`cache.zip`提取緩存時，zip 文件中的所有內容都提取到作業的工作目錄（通常是下拉的存儲庫）中，并且 Runner 不在乎`job A`的存檔是否覆蓋了`job B` 之所以以這種方式工作，是因為為一個 Runner 創建的緩存通常在由可以在**不同體系結構**上運行的緩存使用時才無效（例如，當緩存包含二進制文件時）. 而且由于不同的步驟可能由運行在不同計算機上的運行程序執行，因此這是安全的默認設置. ### Cache mismatch[](#cache-mismatch "Permalink") 在下表中，您可以看到可能導致緩存不匹配的一些原因以及一些解決方法. | 緩存不匹配的原因 | 如何修復 | | --- | --- | | 您使用多個獨立運行器（不在自動縮放模式下）附加到一個項目，而沒有共享緩存 | 您的項目僅使用一個 Runner 或使用啟用了分布式緩存的多個 Runner | | 您在未啟用分布式緩存的自動縮放模式下使用 Runners | 配置自動縮放運行器以使用分布式緩存 | | 安裝了 Runner 的計算機磁盤空間不足，或者，如果設置了分布式緩存，則存儲緩存的 S3 存儲桶空間不足 | 確保清除一些空間以允許存儲新的緩存. 當前，沒有自動的方法可以做到這一點. | | 對于作業中緩存不同路徑的作業，請使用相同的`key` . | Use different cache keys to that the cache archive is stored to a different location and doesn’t overwrite wrong caches. | 讓我們探索一些例子. #### Examples[](#examples "Permalink") 假設您只為項目分配了一個 Runner，因此默認情況下緩存將存儲在 Runner 的計算機中. 如果兩個作業 A 和 B 具有相同的緩存密鑰，但是它們緩存不同的路徑，則即使它們的`paths`不匹配，緩存 B 也會覆蓋緩存 A：當管道第二次運行時，我們希望`job A`和`job B`重用其緩存. ``` stages: - build - test job A: stage: build script: make build cache: key: same-key paths: - public/ job B: stage: test script: make test cache: key: same-key paths: - vendor/ ``` 1. `job A` runs. 2. `public/`作為 cache.zip 緩存. 3. `job B` runs. 4. 先前的緩存（如果有）已解壓縮. 5. `vendor/`作為 cache.zip 緩存，并覆蓋前一個. 6. 下次`job A`運行時，它將使用`job B`的緩存，緩存不同，因此無效. 要解決此問題，請為每個作業使用不同的`keys` . 在另一種情況下，假設您為項目分配了多個運行器，但是未啟用分布式緩存. 第二次運行管道時，我們希望`job A`和`job B`重用其緩存（在這種情況下將有所不同）： ``` stages: - build - test job A: stage: build script: build cache: key: keyA paths: - vendor/ job B: stage: test script: test cache: key: keyB paths: - vendor/ ``` 在這種情況下，即使`key`不同（不必擔心覆蓋），如果作業在后續管道中的不同運行器上運行，您也可能會在每個階段之前"清理"緩存的文件. ## Clearing the cache[](#clearing-the-cache "Permalink") GitLab Runners 使用[緩存](../yaml/README.html#cache)通過重用現有數據來加快作業的執行速度. 但是，這有時可能導致行為不一致. 要從緩存的新副本開始，有兩種方法可以做到這一點. ### Clearing the cache by changing `cache:key`[](#clearing-the-cache-by-changing-cachekey "Permalink") 您所需要做的就是設置一個新的`cache: key` `.gitlab-ci.yml` . 在下一個管道運行中，緩存將存儲在其他位置. ### Clearing the cache manually[](#clearing-the-cache-manually "Permalink") 在 GitLab 10.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41249) . 如果要避免編輯`.gitlab-ci.yml` ，則可以通過 GitLab 的 UI 輕松清除緩存： 1. 導航到項目的**CI / CD>管道**頁面. 2. 單擊" **清除流道緩存"**按鈕以清理緩存. [![Clear Runners cache](https://img.kancloud.cn/0d/08/0d084a044aeb122077d2956f728988da_1273x312.png)](img/clear_runners_cache.png) 3. 在下一次推送時，您的 CI / CD 作業將使用新的緩存. 在后臺，這可以通過在數據庫中增加一個計數器來實現，該計數器的值用于通過將整數附加到`-1` ， `-2`等來為高速緩存創建密鑰.密鑰已生成，舊的緩存不再有效.