Optimizing GitLab for large repositories · Gitlab 中文文檔

# Optimizing GitLab for large repositories > 原文：[https://docs.gitlab.com/ee/ci/large_repositories/](https://docs.gitlab.com/ee/ci/large_repositories/) * [Shallow cloning](#shallow-cloning) * [Git strategy](#git-strategy) * [Git clone path](#git-clone-path) * [Git clean flags](#git-clean-flags) * [Git fetch extra flags](#git-fetch-extra-flags) * [Fork-based workflow](#fork-based-workflow) * [`shell` executor example](#shell-executor-example) * [`docker` executor example](#docker-executor-example) * [Our `.gitlab-ci.yml`](#our-gitlab-ciyml) * [Store custom clone options in `config.toml`](#store-custom-clone-options-in-configtoml) # Optimizing GitLab for large repositories[](#optimizing-gitlab-for-large-repositories "Permalink") 通常，由于克隆和簽出所需的時間，在工作樹中包含超過 5 萬個文件的大型存儲庫通常需要特別考慮. GitLab 和 GitLab Runner 可以很好地處理這種情況，但是需要優化的配置才能有效地執行其操作. 處理大型存儲庫的一般準則很簡單. 以下各節將更詳細地描述每個準則： * 始終以增量方式獲取. 請勿以導致重新創建所有工作樹的方式進行克隆. * 始終使用淺克隆來減少數據傳輸. 請注意，由于 CPU 影響更大，這給 GitLab 實例帶來了更多負擔. * 如果您大量使用基于 fork 的工作流，請控制克隆目錄. * 優化`git clean`標志，以確保刪除或保留可能影響或加快構建速度的數據. ## Shallow cloning[](#shallow-cloning "Permalink") 在 GitLab Runner 8.9 中引入. 默認情況下，GitLab 和 GitLab Runner 始終執行完整克隆. 雖然這意味著已收到來自 GitLab 的所有更改，但通常會導致接收額外的提交日志. 理想情況下，您應始終使用`GIT_DEPTH` ，該數字應較小，例如 10.這將指示 GitLab Runner 執行淺表克隆. 淺克隆使 Git 僅請求給定分支的最新一組更改，最多達到`GIT_DEPTH`變量定義的所需提交`GIT_DEPTH` . 這極大地加快了從 Git 存儲庫獲取更改的速度，特別是如果存儲庫積壓的事務由很多個大文件組成的積壓很長時，因為我們有效地減少了數據傳輸量. 以下示例使 GitLab Runner 淺表克隆僅獲取給定的分支；它不會獲取任何其他分支或標簽. ``` variables: GIT_DEPTH: 10 test: script: - ls -al ``` ## Git strategy[](#git-strategy "Permalink") 在 GitLab Runner 8.9 中引入. 默認情況下，GitLab 配置為始終首選`GIT_STRATEGY: fetch`策略. 如果在磁盤上找到`GIT_STRATEGY: fetch`策略，則會重新使用現有的工作樹. 這與`GIT_STRATEGY: clone`策略不同， `GIT_STRATEGY: clone`一樣，如果找到了工作樹，則會在克隆之前將其刪除. 首選使用`fetch` ，因為它會減少要傳輸的數據量，并且不會真正影響您可能會從 CI 對存儲庫執行的操作. 但是， `fetch`確實需要訪問以前的工作樹. 使用時，這種運作良好， `shell`或`docker`執行，因為這些努力保持 worktrees，默認情況下盡量重復使用它們. 目前不適用于`kubernetes`執行器，并且在使用`kubernetes` `docker+machine`時有限制. `kubernetes`執行器總是克隆到臨時目錄中. GitLab 還提供了`GIT_STRATEGY: none`策略. 這會禁用任何由 GitLab 完成的`fetch`和`checkout`命令，要求您執行這些操作. ## Git clone path[](#git-clone-path "Permalink") 在 GitLab Runner 11.10 中引入. [`GIT_CLONE_PATH`](../yaml/README.html#custom-build-directories)允許您控制在何處克隆源. 如果您在 fork 工作流中大量使用大型存儲庫，則可能會產生影響. 從 GitLab Runner 的角度來看，前叉工作流存儲為具有單獨工作樹的單獨存儲庫. 這意味著 GitLab Runner 無法優化工作樹的使用，您可能必須指示 GitLab Runner 使用它. 在這種情況下，理想情況下，您希望使 GitLab Runner 執行程序僅用于給定項目，而不是在不同項目之間共享，以使此過程更高效. [`GIT_CLONE_PATH`](../yaml/README.html#custom-build-directories)必須在`$CI_BUILDS_DIR` . 當前，不可能從磁盤選擇任何路徑. ## Git clean flags[](#git-clean-flags "Permalink") 在 GitLab Runner 11.10 中引入. [`GIT_CLEAN_FLAGS`](../yaml/README.html#git-clean-flags)允許您控制是否要求對每個 CI 作業執行`git clean`命令. 默認情況下，GitLab 確保您的工作樹在給定的 SHA 上，并且您的存儲庫是干凈的. 設置為`none`時，將禁用[`GIT_CLEAN_FLAGS`](../yaml/README.html#git-clean-flags) . 在非常大的存儲庫上，這可能是理想的，因為`git clean`是磁盤 I / O 密集型的. 使用`GIT_CLEAN_FLAGS: -ffdx -e .build/`控制`GIT_CLEAN_FLAGS: -ffdx -e .build/` （例如）使您可以控制和禁用后續運行之間工作樹中某些目錄的刪除，這可以加快增量生成的速度. 如果您重復使用現有計算機并擁有可用于構建的現有工作樹，則效果最大. 有關[`GIT_CLEAN_FLAGS`](../yaml/README.html#git-clean-flags)接受的確切參數，請參見[`git clean`](https://git-scm.com/docs/git-clean)的文檔. 可用參數取決于 Git 版本. ## Git fetch extra flags[](#git-fetch-extra-flags "Permalink") 在 GitLab Runner 13.1 中[引入](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) . [`GIT_FETCH_EXTRA_FLAGS`](../yaml/README.html#git-fetch-extra-flags) allows you to modify `git fetch` behavior by passing extra flags. 有關更多信息，請參見[`GIT_FETCH_EXTRA_FLAGS`文檔](../yaml/README.html#git-fetch-extra-flags) . ## Fork-based workflow[](#fork-based-workflow "Permalink") 在 GitLab Runner 11.10 中引入. 遵循以上準則，讓我們假設我們想要： * 針對大型項目進行優化（目錄中有超過 5 萬個文件）. * 使用基于分叉的工作流進行貢獻. * 重用現有的工作樹. 預先配置了存儲庫的預配置運行器. * 賽跑者僅分配給項目和所有分叉. 讓我們考慮以下兩個示例，一個使用`shell` executor，另一個使用`docker` executor. ### `shell` executor example[](#shell-executor-example "Permalink") 假設您具有以下[`config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html) . ``` concurrent = 4 [[runners]] url = "GITLAB_URL" token = "TOKEN" executor = "shell" builds_dir = "/builds" cache_dir = "/cache" [runners.custom_build_dir] enabled = true ``` This `config.toml`: * 使用`shell`執行器， * 指定一個自定義`/builds`目錄，其中將存儲所有克隆. * 啟用指定`GIT_CLONE_PATH` ， * 一次最多運行 4 個作業. ### `docker` executor example[](#docker-executor-example "Permalink") 假設您具有以下[`config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html) . ``` concurrent = 4 [[runners]] url = "GITLAB_URL" token = "TOKEN" executor = "docker" builds_dir = "/builds" cache_dir = "/cache" [runners.docker] volumes = ["/builds:/builds", "/cache:/cache"] ``` This `config.toml`: * 使用`docker` executor， * 在磁盤上指定將存儲所有克隆的自定義`/builds`目錄. 我們在主機上掛載`/builds`目錄，以使其在后續運行之間可重復使用，并允許其覆蓋克隆策略. * 默認情況下已啟用，因此未啟用指定`GIT_CLONE_PATH`功能. * 一次最多運行 4 個作業. ### Our `.gitlab-ci.yml`[](#our-gitlab-ciyml "Permalink") 一旦配置了執行程序，就需要微調`.gitlab-ci.yml` . Our pipeline will be most performant if we use the following `.gitlab-ci.yml`: ``` variables: GIT_DEPTH: 10 GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_NAME build: script: ls -al ``` 上面配置了： * 淺克隆 10，以加快后續`git fetch`命令的速度. * 自定義克隆路徑，使我們可以在父項目和所有分支之間重用工作樹，因為我們對所有分支使用相同的克隆路徑. 為什么要使用`$CI_CONCURRENT_ID` ？主要原因是要確保使用的工作樹在項目之間不沖突. `$CI_CONCURRENT_ID`表示給定執行器中的唯一標識符，因此只要我們使用它來構造路徑，就可以確保該目錄不會與其他正在運行的并發作業沖突. ### Store custom clone options in `config.toml`[](#store-custom-clone-options-in-configtoml "Permalink") 理想情況下，所有與作業相關的配置都應存儲在`.gitlab-ci.yml` . 但是，有時希望使這些方案成為 Runner 配置的一部分. 在以上 Forks 的示例中，使此配置對于用戶可發現可能是首選，但這會帶來管理開銷，因為需要為每個分支更新`.gitlab-ci.yml` . 在這種情況下，可能希望保持`.gitlab-ci.yml`克隆路徑不可知，但是將其配置為 Runner. 我們可以使用以下規范擴展[`config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html) ，如果`.gitlab-ci.yml`不覆蓋它，它將由 Runner 使用： ``` concurrent = 4 [[runners]] url = "GITLAB_URL" token = "TOKEN" executor = "docker" builds_dir = "/builds" cache_dir = "/cache" environment = [ "GIT_DEPTH=10", "GIT_CLONE_PATH=$CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_NAME" ] [runners.docker] volumes = ["/builds:/builds", "/cache:/cache"] ``` 這使得克隆配置成為給定 Runner 的一部分，并且不需要我們更新每個`.gitlab-ci.yml` .