在GitLab CI作业中实现最小化上下文的抉择

44次阅读

问题描述

正在为项目设计构建和部署流水线。他们有两个作业：
– build — 构建带有应用程序的Docker镜像并将其推送到容器注册表。
– deploy — 与编排器通信，部署新版本。

用户有一个疑问：在两种选择中，哪个更好？
1. 在deploy作业中获取完整的存储库，尽管只需要一个静态配置（部署规范）。
2. 使用构件传递所需的配置文件从build作业到deploy作业，并将GIT_STRATEGY设置为none。

这两个选项在deploy作业环境中有所不同：
1. deploy作业具有与build相同的上下文（完整存储库）：
– 优点：
– 默认行为（不需要额外的代码和操作）。
– 缺点：
– deploy作业环境变得杂乱。
– deploy作业的真实上下文是隐式的。
– 未来可能被滥用。

build作业使用构件发布所需的配置给deploy作业：
优点：
- deploy作业明确不访问任何不必要的内容。
缺点：
- 需要配置deploy作业不获取存储库。
- 需要配置build作业发布构建物。
- 需要配置deploy作业使用构件。
- 构件始终包含存储库中未更改的文件（担心滥用构件）。

请帮助用户做出选择。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

建议方案

由于您的用例非常简单，所以依赖于GIT_STRATEGY=fetch可能已经足够，正如您所说，这是默认行为。

您应该谨慎使用不必要的构件，因为它们会上传到GitLab服务器。

要回答您的问题，通常取决于一些因素，例如存储库的大小、网络连接、Runner执行器类型等。一种选择是在构建过程中配置缓存（在本例中在流水线级别），对于部署，只需设置GIT_STRATEGY=none：

default:
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - deployment.spec.config
build:
  stage: build
  script:
    - build something
deploy:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script:
    - push-deployment ./deployment.spec.config

在这里，一个附加的好处（取决于您的构建过程）是在针对同一分支运行多个流水线时，有可能缓存依赖项。请注意，您只能缓存相对于项目构建目录的文件。

感谢您的回答。第一句话不太清楚，您是否是想说“依赖于 GIT_STRATEGY=fetch 可能已经足够，并且正如您所说，这是默认行为”？
我发誓在我的脑海中听起来很正确。我编辑了回答。事实上，那确实是我的意思。我想表达的是保持简单。归根结底，我会选择产生最快、可重复的流水线。如果这意味着使用构件，因为以这种方式快速传输一个配置文件比获取整个存储库要快，那就这么做吧。另一个例子是，如果GitLab服务器托管在云A中，通过有限吞吐量的VPN连接到云B，在这种情况下，本地缓存可能是一个不言而喻的选择。感谢！

正文完