Optimizing GitLab for large repositories

原文:https://docs.gitlab.com/ee/ci/large_repositories/

Optimizing GitLab for large repositories

通常,由于克隆和签出所需的时间,在工作树中包含超过 5 万个文件的大型存储库通常需要特别考虑.

GitLab 和 GitLab Runner 可以很好地处理这种情况,但是需要优化的配置才能有效地执行其操作.

处理大型存储库的一般准则很简单. 以下各节将更详细地描述每个准则:

  • 始终以增量方式获取. 请勿以导致重新创建所有工作树的方式进行克隆.
  • 始终使用浅克隆来减少数据传输. 请注意,由于 CPU 影响更大,这给 GitLab 实例带来了更多负担.
  • 如果您大量使用基于 fork 的工作流,请控制克隆目录.
  • 优化git clean标志,以确保删除或保留可能影响或加快构建速度的数据.

Shallow cloning

在 GitLab Runner 8.9 中引入.

默认情况下,GitLab 和 GitLab Runner 始终执行完整克隆. 虽然这意味着已收到来自 GitLab 的所有更改,但通常会导致接收额外的提交日志.

理想情况下,您应始终使用GIT_DEPTH ,该数字应较小,例如 10.这将指示 GitLab Runner 执行浅表克隆. 浅克隆使 Git 仅请求给定分支的最新一组更改,最多达到GIT_DEPTH变量定义的所需提交GIT_DEPTH .

这极大地加快了从 Git 存储库获取更改的速度,特别是如果存储库积压的事务由很多个大文件组成的积压很长时,因为我们有效地减少了数据传输量.

以下示例使 GitLab Runner 浅表克隆仅获取给定的分支; 它不会获取任何其他分支或标签.

  1. variables:
  2. GIT_DEPTH: 10
  3. test:
  4. script:
  5. - ls -al

Git strategy

在 GitLab Runner 8.9 中引入.

默认情况下,GitLab 配置为始终首选GIT_STRATEGY: fetch策略. 如果在磁盘上找到GIT_STRATEGY: fetch策略,则会重新使用现有的工作树. 这与GIT_STRATEGY: clone策略不同, GIT_STRATEGY: clone一样,如果找到了工作树,则会在克隆之前将其删除.

首选使用fetch ,因为它会减少要传输的数据量,并且不会真正影响您可能会从 CI 对存储库执行的操作.

但是, fetch确实需要访问以前的工作树. 使用时,这种运作良好, shelldocker执行,因为这些努力保持 worktrees,默认情况下尽量重复使用它们.

目前不适用于kubernetes执行器,并且在使用kubernetes docker+machine时有限制. kubernetes执行器总是克隆到临时目录中.

GitLab 还提供了GIT_STRATEGY: none策略. 这会禁用任何由 GitLab 完成的fetchcheckout命令,要求您执行这些操作.

Git clone path

在 GitLab Runner 11.10 中引入.

GIT_CLONE_PATH允许您控制在何处克隆源. 如果您在 fork 工作流中大量使用大型存储库,则可能会产生影响.

从 GitLab Runner 的角度来看,前叉工作流存储为具有单独工作树的单独存储库. 这意味着 GitLab Runner 无法优化工作树的使用,您可能必须指示 GitLab Runner 使用它.

在这种情况下,理想情况下,您希望使 GitLab Runner 执行程序仅用于给定项目,而不是在不同项目之间共享,以使此过程更高效.

GIT_CLONE_PATH必须在$CI_BUILDS_DIR . 当前,不可能从磁盘选择任何路径.

Git clean flags

在 GitLab Runner 11.10 中引入.

GIT_CLEAN_FLAGS允许您控制是否要求对每个 CI 作业执行git clean命令. 默认情况下,GitLab 确保您的工作树在给定的 SHA 上,并且您的存储库是干净的.

设置为none时,将禁用GIT_CLEAN_FLAGS . 在非常大的存储库上,这可能是理想的,因为git clean是磁盘 I / O 密集型的. 使用GIT_CLEAN_FLAGS: -ffdx -e .build/控制GIT_CLEAN_FLAGS: -ffdx -e .build/ (例如)使您可以控制和禁用后续运行之间工作树中某些目录的删除,这可以加快增量生成的速度. 如果您重复使用现有计算机并拥有可用于构建的现有工作树,则效果最大.

有关GIT_CLEAN_FLAGS接受的确切参数,请参见git clean的文档. 可用参数取决于 Git 版本.

Git fetch extra flags

在 GitLab Runner 13.1 中引入 .

GIT_FETCH_EXTRA_FLAGS allows you to modify git fetch behavior by passing extra flags.

有关更多信息,请参见GIT_FETCH_EXTRA_FLAGS文档 .

Fork-based workflow

在 GitLab Runner 11.10 中引入.

遵循以上准则,让我们假设我们想要:

  • 针对大型项目进行优化(目录中有超过 5 万个文件).
  • 使用基于分叉的工作流进行贡献.
  • 重用现有的工作树. 预先配置了存储库的预配置运行器.
  • 赛跑者仅分配给项目和所有分叉.

让我们考虑以下两个示例,一个使用shell executor,另一个使用docker executor.

shell executor example

假设您具有以下config.toml .

  1. concurrent = 4
  2. [[runners]]
  3. url = "GITLAB_URL"
  4. token = "TOKEN"
  5. executor = "shell"
  6. builds_dir = "/builds"
  7. cache_dir = "/cache"
  8. [runners.custom_build_dir]
  9. enabled = true

This config.toml:

  • 使用shell执行器,
  • 指定一个自定义/builds目录,其中将存储所有克隆.
  • 启用指定GIT_CLONE_PATH
  • 一次最多运行 4 个作业.

docker executor example

假设您具有以下config.toml .

  1. concurrent = 4
  2. [[runners]]
  3. url = "GITLAB_URL"
  4. token = "TOKEN"
  5. executor = "docker"
  6. builds_dir = "/builds"
  7. cache_dir = "/cache"
  8. [runners.docker]
  9. volumes = ["/builds:/builds", "/cache:/cache"]

This config.toml:

  • 使用docker executor,
  • 在磁盘上指定将存储所有克隆的自定义/builds目录. 我们在主机上挂载/builds目录,以使其在后续运行之间可重复使用,并允许其覆盖克隆策略.
  • 默认情况下已启用,因此未启用指定GIT_CLONE_PATH功能.
  • 一次最多运行 4 个作业.

Our .gitlab-ci.yml

一旦配置了执行程序,就需要微调.gitlab-ci.yml .

Our pipeline will be most performant if we use the following .gitlab-ci.yml:

  1. variables:
  2. GIT_DEPTH: 10
  3. GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_NAME
  4. build:
  5. script: ls -al

上面配置了:

  • 浅克隆 10,以加快后续git fetch命令的速度.
  • 自定义克隆路径,使我们可以在父项目和所有分支之间重用工作树,因为我们对所有分支使用相同的克隆路径.

为什么要使用$CI_CONCURRENT_ID ? 主要原因是要确保使用的工作树在项目之间不冲突. $CI_CONCURRENT_ID表示给定执行器中的唯一标识符,因此只要我们使用它来构造路径,就可以确保该目录不会与其他正在运行的并发作业冲突.

Store custom clone options in config.toml

理想情况下,所有与作业相关的配置都应存储在.gitlab-ci.yml . 但是,有时希望使这些方案成为 Runner 配置的一部分.

在以上 Forks 的示例中,使此配置对于用户可发现可能是首选,但这会带来管理开销,因为需要为每个分支更新.gitlab-ci.yml . 在这种情况下,可能希望保持.gitlab-ci.yml克隆路径不可知,但是将其配置为 Runner.

我们可以使用以下规范扩展config.toml ,如果.gitlab-ci.yml不覆盖它,它将由 Runner 使用:

  1. concurrent = 4
  2. [[runners]]
  3. url = "GITLAB_URL"
  4. token = "TOKEN"
  5. executor = "docker"
  6. builds_dir = "/builds"
  7. cache_dir = "/cache"
  8. environment = [
  9. "GIT_DEPTH=10",
  10. "GIT_CLONE_PATH=$CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_NAME"
  11. ]
  12. [runners.docker]
  13. volumes = ["/builds:/builds", "/cache:/cache"]

这使得克隆配置成为给定 Runner 的一部分,并且不需要我们更新每个.gitlab-ci.yml .