为什么gitlab-ci默认为每个作业使用git clone而不是先构建docker映像？

Question

Gitlab-ci的默认模式是在管道中的每个作业中使用git clone。 这非常耗时，特别是因为克隆后我们需要安装/更新所有依赖项。 我想翻转管道的顺序，从git clone + docker build开始，然后使用该映像运行所有后续作业，而无需为每个作业克隆和重建。

我想念什么吗？ 如果我已经有使用当前代码的图像，是否有任何理由要为每个作业分别克隆存储库？

Answer 1

使用配置项的原因之一是在全新状态下执行回购。如果您跳过某些作业中的git clone过程，则无法完成此操作。作业可以通过删除文件或生成新文件来修改仓库的状态。作业之间只能共享管道中明确记录的artifacts，其他任何地方都不能共享。

Answer 2

您什么都不丢失。如果您知道自己在做什么，则无需为管道中的每个阶段克隆存储库。如果将GIT_STRATEGY变量设置为none，则测试作业或任何作业将更快地运行，您只需运行docker pull命令和所需的测试即可。即使启动许多并行作业，也只需确保使用正确的docker映像即可。例如，您可以使用CI_COMMIT_REF_NAME作为docker映像名称的一部分。

关于为何GitLab默认使用git clone的原因，我的猜测是这是最令人惊讶的行为。如果您想象有人对GitLab陌生，对CI陌生，那么如果每个作业都简单地克隆了整个存储库，对他们来说起来就容易得多。您还必须记住，并非每个人都在自己的工作中构建docker映像。我猜想，最常见的设置方式是使用不需要编译的编程语言（例如python），或者有一个build作业会生成二进制文件，并且然后执行一个运行二进制文件的test作业。然后，他们可以使用artifacts将二进制文件从构建作业发送到测试作业。

这很容易并且有效。然后，当人们意识到很多测试工作只是花在克隆存储库上时，他们可能会研究如何更改GIT_STRATEGY并做其他事情来优化他们的特定构建。