在我看来，快照依赖的功能完全取代了TeamCity中已完成构建触发器的功能。任何人都可以解释更多这些方法的影响，如果他们导致不同的连锁行为？作为一个例子，如果我有一个构建链A-> BTeamCity中快照依赖和完成构建触发器之间的区别是什么？
链的实际行为在这三个设置之间是否有任何不同？
我知道可以将快照依赖视为所有依赖项的“AND”操作，而完成构建触发的作用类似于依赖项之间的“或”操作。但是在一个顺序链中，有没有区别？
感谢， 斯科特
正如你所说，有一个很大的区别，如果一个配置快照取决于多个其他CONFIGS（Z快照取决于X和Y）。但你对此不感兴趣......
的确可以这么说，在普通的A-> B场景下，Setups1.3接近于等价。当然，只有当触发A和B的事件是一对一时（例如，A和B都在相同的VCS根上触发;或者它们使用不同的VCS根，但只能手动触发）。如果这是真的，那么你的A-> B链是非常平凡的，并且可能在单个构建配置中实现。
浮现在脑海其他细微的差别：
传递参数环比下滑。
%foo%并使用%dep.A.foo%在B中重用它。这非常方便，因为您不需要担心在A和B之间保持%foo%的同步值。%foo%的A-> B链，将在“运行...”对话框中指定值）。由于TC无法通过向上链（从B到A），因此您必须真正触发A并在那里指定自定义值。当A完成时，它将触发B，这将超过自定义值。这是设置3.调度。
不同的VCS根。
在一般情况下，我同意快照依赖的“拉”的性质（设置2）具有更大的吸引力。如果需要，与触发器组合（设置3）。
“Snapshot Dependency”和“Finished Build”触发器有很大不同。一个基本上是“推”操作，而另一个是“拉”操作。
设定1： 如果我有建立CONFIGS 甲和乙其中乙对甲一个“完成生成”触发，那么相反的行为是真实的。触发乙将对一个没有影响，但引发一个将有效地触发乙一旦完成。
设置2： 如果我有相同的设置，而是乙对一个快照依赖，那么只要乙被触发，一个将首先运行，或至少检查查看是否需要运行，然后运行B。 IF只有A被触发，则不会触发B。
设置3： 设置3稍有不同，因为它不只是依赖于“完成生成”触发器或快照依赖。它还取决于最初的触发器（VCS，预定的或其他）。例如，如果你有一个一个 VCS触发器，乙既有“完成构建”触发器和“快照依赖”上一个，那么你得到有效的安装程序的行为1 一个会在VCS更改时触发，B将在A（使用相同的快照）后触发。实际上，如果没有快照设置，则不能保证B将使用与A相同的快照，这可能是也可能不是您想要的。所以一般来说，当你想要一个“从左到右”的触发过程时，你可以使用完成的构建触发器和快照依赖来保证构建抵押品的神圣性。
如果，另一方面，你有你的初始触发（VCS或计划或其他）设置在乙，则具有“已完成构建”触发是有点作废，因为乙总是会首先触发（但不运行），然后它将触发它的所有依赖关系并在完成后自动运行。
希望有帮助。谢谢！
感谢您的详细解释。 在我的情况下，共享参数和稀有资源非常少见，所以如果有不同的VCS根需要特定的行为，我可能会默认只有快照依赖（setup 2），并使用组合（setup 3）。 –
你能否在安装程序3中澄清一下，如果snapshop依赖项具有“不运行新版本如果有合适的版本”选项，则A会运行两次** UNCHECKED **？如...在某些事件触发A时，当A完成时，_Finished Build_开始并尝试将B放入队列中，则_Snapshot依赖关系_在B排队之前再次启动并将A放入队列中。当我测试这个设置时，它不会在队列中放置另一个A，但我认为它应该在理论上。如果完成生成触发器存在，TeamCity是否有内部逻辑来忽略快照依赖项的排队步骤？ –
即使未选中此选项，我也不认为A应该重新排队。这将是非常不切实际的，我想不出任何可能渴望这种行为的人。 （我想你也不想要这种行为，你只是想知道这个选项如果不是这个*）。我相信这个选项的作用是这样的：踢A，让B触发。两者都运行过一次。现在只需手动触发B，自上次B构建以来没有任何代码更改。应该再次触发A吗？这就是这个选项的作用。 – sferencik