快照依赖
通过为构建(例如,构建B)设置另一个构建(构建A)源代码的 快照依赖项 ,您可以确保只有在构建A运行并完成后,构建B才会启动。 我们称构建 A 为 依赖 构建,而构建 B 是一个 被依赖 构建。
构建配置设置 | 依赖项 页面显示已配置的依赖项;此页面的 快照依赖 部分允许预览构建链及其配置。 预览显示了链的构建情况;配置了自动触发器的构建将被标记为 图标。
快照依赖具有以下选项:
选项 | 描述 |
---|---|
依赖于 | 指定依赖的构建配置。 在我们的示例中,选择构建 A 作为当前构建 B 的依赖项。 |
执行修订版本同步 | 对于链中的所有构建,如果通过此选项 已启用 (默认情况下)由快照依赖项链接,TeamCity 将使用相同来源的快照(例如,相同 VCS 根的相同修订版)。 这是一个推荐的设置,用于需要使用源文件相同状态来成功构建的配置。 如果您为快照依赖项 禁用 此选项,那么当 依赖项构建 被提升到当前构建配置时,当前构建配置的构建将使用来源的最新修订版,而不是与提升的依赖项对应的修订版。 当构建没有严格的源依赖性时(例如,与包和部署步骤一样),这是有用的。 在我们的例子中,如果构建 B 的快照依赖性禁用了此选项,那么行为如下:构建 A 在修订 1.2 上启动,完成后,升级为构建 B。 在启动 B 的时候,TeamCity 将找到构建 B 的最新修订版本(比如说 1.3)。 请注意,源的快照规则仅应用于通过启用选项的快照依赖关联的 构建链的部分。 |
如果有合适的构建,则不要运行新构建 | 如果启用此选项,那么如果已经存在具有适当源修订版本的正在运行或已完成的依赖构建,TeamCity 将不会运行新的依赖构建。 另请参见 适用的构建。
|
只使用合适的成功构建 | 新触发的构建只会使用成功完成的 合适构建 作为依赖。 如果最新完成的合适构建失败,它将被重新运行。 |
在同一代理上运行构建 | 当启用此功能并且 B 快照依赖于 A 时,每个 B 构建都会在运行相同构建链的 A 构建的相同代理上运行。
|
在依赖失败时/在启动失败或取消依赖时 | 如果依赖关系失败,您可以通过选择以下选项之一来管理依赖构建的状态:
|
在快照依赖性方面,一个 合适的 构建是可以替代排队依赖构建的构建,它位于一个 构建链 中。 也就是说,作为构建链的一部分的排队构建可以被放弃,而依赖于它的构建可以改为依赖另一个排队中、正在运行或已经完成的 "合适" 的构建。 此行为只在对应的快照依赖性的 "如果存在合适的构建,不运行新的构建 " 选项启用时才有效。
为了让构建被认为是"适合的",它应满足所有这些条件:
它必须属于相同或默认的分支。
它必须使用与正在处理的整个排队构建链相同的 源快照。 如果构建配置具有相同的 VCS 设置,这意味着 相同源代码的修订版本。 如果 VCS 设置有所不同(VCS 根或检出规则),这意味着 在某一时刻同时获取的修订版本。
必须成功(如果启用了 "只从合适的构建中使用成功的构建" 快照依赖选项)。
必须是常规版本,而不是 personal build。
它必须没有自定义参数,包括通过
reverse.dep.
参数设置的(相关功能请求: TW-23700)。依赖项构建配置"的"重建"操作不得触发原始构建。
它必须没有任何阻止有效版次计算的 VCS 设置,请参见 更多详情。
如果禁用了 "如果有合适的构建,则不运行新的构建" 选项,那么当前的构建配置快照将没有任何其他的依赖。
正在运行的构建没有“挂起”。
构建配置的设置自构建(即,使用当前构建配置设置运行的构建)以来未发生更改。 这也包括不改变所有父项目的构建配置的参数。 您可以通过比较
.teamcity/settings/digest.txt
文件来检查在多个构建之间设置是否发生了变化,该文件位于 隐藏构建的构件中。如果除了快照依赖之外还有工件依赖,那么合适的构建应该具有工件。 否则,没有发布工件的构建和在 清理 过程中删除了工件的构建同样合适。
所有的依赖构建(当前构建所依赖的构建)都是"合适的",并且已经被适当地合并。
VCS 根中的某些设置可以有效地禁用构建重用。 这些设置包括:
Subversion: 签出,但忽略更改 模式
CVS: 按标签签出 模式
Perforce: 流 或 客户端 连接设置,或标签被指定为 要签出的标签/修订版
Starteam:签出模式选项设置为 查看标签 或 推广日期
始终运行新构建 行为(快照依赖如果有合适的构建,则不要运行新构建 设置已禁用)仅影响主配置构建。 当使用 并行测试 功能时,动态生成的虚拟构建配置可能仍会重用其先前的结果。 如果未检测到新的存储库提交,则只有先前失败的测试批次会运行新的构建,而成功的批次会被重用。
在下图中,“Composite Conf”配置依赖于“Maven App”配置。 后者以两个并行批次运行其测试。 请注意,主“Maven app”构建 #18 被重新触发,而动态生成的“Maven app 1”配置重用了其先前成功的构建(#12)。

您可以强制 TeamCity 重新运行所有虚拟配置构建。 在这种情况下,即使未发现新的存储库提交,每个单独的测试批次也会重新运行。

为此,请将 teamcity.internal.splitBuild.dependency.takeStartedBuildWithSameRevisions=false
参数 添加到具有并行测试功能的配置中。
要将此行为应用于服务器上的所有配置,请将此参数添加到 内部属性 列表中。