TeamCity中快照依赖关系和完成构建触发器之间有什么区别？

Question

在我看来,快照依赖的功能完全取代了TeamCity中完成构建触发器的功能.任何人都可以解释这些方法的效果,如果它们导致不同的链行为？例如,如果我有一个A-> B的构建链

链条在这三种设置之间的实际行为有何不同？

• 设置1:B中A的单个完成构建触发器.
• 设置2:B中A的单个快照依赖性.
• 设置3:B中定义的A和A快照依赖关系的完成构建触发器.

我理解,可以将Snapshot Dependency视为所有依赖项的"AND"操作,而Finished Build Trigger的工作方式类似于dependees中的"OR"操作.但在顺序链的背景下,有什么区别吗？

谢谢,斯科特

Answer 1

"快照依赖"和"完成构建"触发器非常不同.一个基本上是"推"操作,而另一个是"拉"操作.

设置1: 如果我有建CONFIGS 一个和乙在那里乙对"已完成构建"触发一个,那么相反的行为是真实的.触发B对A没有影响,但触发A将在B完成后有效触发.

设置2: 如果我具有完全相同的设置但是B具有对A的快照依赖性,那么每当触发B时,A将首先运行,或者至少在运行B之前检查它是否需要运行.如果仅触发A,则不会触发B.

设置3: 设置3略有不同,因为它不依赖于"完成构建"触发器或快照依赖性.它还取决于初始触发器(VCS,预定或其他).例如,如果你有一个VCS触发一个,和乙既有"完成构建"触发器和"快照依赖"的一个,那么你得到有效设置1.行为一将得到对VCS的变化,并引发乙会在A之后触发(使用相同的快照).实际上,如果没有快照设置,则无法保证B将使用与A相同的快照,这可能是也可能不是您想要的.

所以一般来说,当你想要一个"从左到右"的触发过程时,你可以使用BOTH完成的构建触发器和快照依赖关系来保证构建抵押品的神圣性.

另一方面,如果你在B上有初始触发器(VCS或预定或其他)设置,那么"完成构建"触发器有些无效,因为B将始终首先被触发(但不会被运行),然后它将触发所有依赖项并在完成后自动运行.

希望有所帮助.谢谢!

Answer 2

正如您所说，如果配置快照依赖于多个其他配置（Z 快照依赖于 X 和 Y），则存在很大差异。但你对此不感兴趣...

确实，在简单的 A->B 场景中，设置 1 .. 3 接近等效。当然，前提是触发A和B的事件是一对一的（例如A和B都在同一VCS根上触发；或者它们使用不同的VCS根但仅手动触发）。如果这是真的，那么您的 A->B 链就非常简单，并且可以在单个构建配置中实现。

我想到的其他细微差别：

1. 沿链传递参数。

   • 假设 A 和 B 共享一些用户定义的参数“foo”。A->B 快照依赖关系允许您%foo%在 A 中定义并在 B 中使用 重用它%dep.A.foo%。这真的很方便，因为您无需担心%foo%A 和 B 之间的值保持同步。
   • 现在假设您想要使用自定义值手动触发 A->B 链%foo%（您将在“运行...”对话框中指定该值）。
   • 由于 TC 无法将值沿链向上传递（从 B 到 A），因此您必须真正触发 A 并在那里指定自定义值。当A完成后，会触发B，B会超越自定义值。这就是设置 3。
   • 您无法通过设置 2 实现相同的效果，即通过使用自定义值触发 B。自定义值无法传递给 A。

2. 调度。

   • 假设您的资源稀缺，并且 B 不可能每次提交都运行。最终，B 的每次运行都会“包含”（覆盖）多个 VCS 提交。同时，A每次提交运行都没有问题。
   • 在设置 1 和 3 中，如果 A 上有 VCS 触发器，您最终会得到
     • 每次提交都会运行 A
     • 具有“聚合”提交的 B 运行（每次运行涵盖多个更改）
   • 在设置 2 中，如果您仅在 B 上有一个 VCS 触发器，那么您最终将在A和 B中获得聚合提交。这可能是您想要的，也可能不是您想要的...

3. 不同的 VCS 根。

   • 如果 A 和 B 具有不同的 VCS 根，则设置 1（仅在 A 上使用 VCS 触发）和设置 2（仅在 B 上使用 VCS 触发）的行为将截然不同。

总的来说，我同意快照依赖项（设置 2）的“拉动”性质更具吸引力。如果需要，可与触发器结合使用（设置 3）。