【问题标题】:How to stop TeamCity from rebuilding docker dependencies every time?如何阻止 TeamCity 每次都重建 docker 依赖项?
【发布时间】:2021-01-20 23:29:53
【问题描述】:

我有一个 TeamCity 构建项目,它使用十几个 Docker 容器的构建版本参数化 docker-compose.yml 模板,因此为了从每个容器中获取 build_counter,我将它们设置为 docker 中的快照依赖项-撰写构建作业。每个容器的 Dockerfile 和其他文件都在自己的 BitBucket 存储库中,并且它们具有相应文件的触发器。在 docker-compose 构建的快照依赖项中,我将它们设置为“如果有合适的构建,则不要运行新构建”,但它仍然尝试运行所有依赖构建,即使它们各自没有任何变化回购。

这使得应该非常简单和快速的构建变成了一个非常长的构建。通常情况下,其中一个依赖构建会因“无法收集更改:连接被拒绝”而失败,我怀疑这与 TC 试图同时访问所有这些不同的存储库有关。

每次运行 docker-compose 构建时我可以做些什么来不触发每个依赖项的构建?

编辑:

以下是 docker-compose.yml.j2 的示例:http://termbin.com/b2xy

显然,我已经对其进行了清理以便共享,我们真正的 docker-compose 模板列出了大约十几个服务。

以下是其中一项服务的 Dockerfile 示例:http://termbin.com/upins

【问题讨论】:

  • 当所有存储库都在构建时,TC 是否显示任何存储库中的未决更改?
  • 不,它们都显示“没有变化”。
  • 你能分享一个 dockerfile 吗?有些命令会使构建缓存无效并导致所有后续命令再次运行而不是命中缓存。
  • 我编辑了问题以包含示例。
  • 可能有帮助,您可能已经使用 RTFM。 Snapshot Dependencies。这里的一些东西解释了为什么 compose 构建配置没有将任何 Dockerfile 构建配置计算为“合适的”

标签: docker docker-compose teamcity bitbucket


【解决方案1】:

与其每次都更改构建的源代码(参数化的 docker-compose.yml)和蛮力构建,不如考虑独立构建容器,同时使用版本增量和标签对其进行标记。构建后将图像存储在本地注册表中。使用 docker-compose 来满足您的运行时需求。 docker-compose 可以使用多个 yaml 文件,因此如果您需要其他图像用于特定构建,只需拉取您需要的其他图像。对于生产使用另一个 yaml 文件来组成要运行的系统。将 LABEL 添加到 Dockerfile。请参阅http://label-schema.org//rc1/ 了解一组适合您需求的标签。

【讨论】:

  • 我不确定我是否理解您的提议。目前容器在不同的 TC 项目中构建,但是 docker-compose build 项目需要知道每个容器最后一次成功构建的 build_counter,所以我们将它们设置为快照依赖项。您是否建议让每个容器构建作业生成自己的 docker-compose sn-p,然后使用 docker-compose 的“-f”选项在运行时合并它们?此外,我编辑了问题以提供一些我们正在做的事情的例子。
  • 一开始你的堆栈不清楚。我建议不要使用快照,因为它们可能随时更改,因此每次都会导致构建(尤其是 package.json 依赖项),构建图像并标记它们,以便您可以依赖注册表中的版本而不是其他构建。换句话说,解耦。
  • TC 有单独的线程监视 repo,并将触发所有涉及的构建。据我所知,TC 不看 Nexus。
  • 好的,但是如果我删除快照依赖项,我将无法从我的 docker-compose 构建中的 docker 构建访问构建计数器变量(即 %dep.MyProject_AServiceBuild.build.counter%) .还有其他方法可以引用这些变量吗?
  • 更新了我的答案,包括在 Dockerfile 中使用 LABEL
【解决方案2】:

我知道这是一个老问题,但我遇到了这个问题,你不能做听起来合理的事情,即在不重建的情况下获得最近的绿色构建。这部分是因为 Jetbrains 设计了快照依赖项。

基本思想是依赖关系是用于代码的同步修订:也就是说,如果您在某个时间构建 Compose,它不仅需要使用该时间点自己的源代码版本,还需要使用也来自那个时间点的所有依赖项,无论是否有任何重大变化。

在我的示例中,总是有更改,因为同一个 repo 用于许多项目,并且有不相关的更改不会触发构建,但会使项目出现落后并导致构建。

如果您的依赖项没有更改并且没有显示未决更改,则不应构建它们。在这种情况下,您需要勾选“如果有合适的版本,请不要运行新版本”。 “强制修订同步”有点令人困惑。如果勾选,它将在您的构建被触发后找到与第一个构建匹配的旧构建。如果不勾选,它可以使用较新的版本。

【讨论】:

    猜你喜欢
    • 2012-04-29
    • 2021-10-21
    • 1970-01-01
    • 2011-09-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多