gitlab-ci 中的增量更新答案

【问题标题】：Incremental update in gitlab-cigitlab-ci 中的增量更新
【发布时间】：2018-10-19 17:38:39
【问题描述】：

社区！

我工作的公司正在转向 git 和 Gitlab-CI。我们有相当大的代码库——下载源代码大约需要 10 分钟，从 nexus 下载补充内容大约需要 20 分钟，然后构建大约需要 50 分钟。所以增量构建是绝对必要的——因此我们可以在几分钟内获取源代码并只构建更新的文件，而不是超过 1 小时。

不幸的是，GitLab 的 CI 默认策略（尤其是 fetch）对增量构建不起作用，因为它们硬编码了“git clean -ffdx”，它会删除所有未跟踪的文件，因此需要完全重建。我最终开发了自己的更新序列：

git 初始化
git fetch --tags $CI_REPOSITORY_URL +refs/heads/:refs/remotes/origin/
git config remote.origin.url $CI_REPOSITORY_URL
git checkout -B $CI_BRANCH_NAME origin/$CI_BRANCH_NAME

此脚本似乎在新计算机上运行（充当克隆），以及更新现有存储库。同时我不确定它是否正常工作，因为它几乎是无声的。

问题 1：签出到任意分支的顺序是否正确？问题2：它之后是否需要 git merge 或 git pull 命令？问题 3：有没有办法通过此特定更新获取更改文件的列表（类似于 git pull 所做的）。这在我们之前的 CI 系统上解决构建问题非常方便问题 4（与 #3 有关）：有没有办法获取当前更新中的提交列表？如果在远分支之间移动，这无关紧要，但在更新同一个分支时可能非常有用

【问题讨论】：

标签： git gitlab gitlab-ci

【解决方案1】：

您应该在 CI 作业上为支持增量构建的未跟踪文件配置 cache 属性。您列出的路径将在作业之间缓存，以便您可以执行增量构建等操作。

作为快速入门，您可以通过简单地将untracked 设置为 true 来缓存所有未跟踪的文件。

ci_job:
  cache:
    untracked: true

【讨论】：

是的，尝试缓存在我的 TODO 列表中。 GitLab 支持也建议这样做。但是，我担心缓存然后恢复 30Gb 的文件。与仅增量更新相比，这是否足够快？
30 GB 似乎很多。如果您绝对必须在作业之间拥有如此大量的数据，也许您可以配置一个专门的运行器来构建这个处理所有额外文件的项目。
在我有限的经验中，git checkout 总是从头开始，所以构建总是一个完整的构建，除非你的构建系统使用文件内容哈希而不是时间戳。为了解决这个问题，我们是否需要缓存整个源代码树并提供一个只更新已更改的源文件的命令？