我正在尝试在TeamCity 6中配置一组构建配置，并尝试以最简洁的方式为TeamCity启用特定需求建模。
我有一组验收测试（大约4-8个测试套件，按照他们所属系统的功能区域分组）我希望并行运行（我将它们建模为构建配置，这样它们就可以了分布在一组代理商中。）
从我最初的研究开始，似乎有一个AcceptanceTests元构建配置通过Snapshot dependencies引入一组单独的Acceptance测试配置应该可以解决问题。然后，我要做的就是说我的Commit构建配置应该触发AcceptanceTests并且它们都会被拉入。所以，我们说我也有AcceptanceSuiteA，{{1} }和AcceptanceSuiteB
到目前为止，非常好（我知道我也可以转向另一种方式并导致AcceptanceSuiteC配置触发Commit，AcceptanceSuiteA和AcceptanceSuiteB - 问题我需要手动汇总结果，以确定整体验收测试的整体成功。）
复杂的一点是，虽然AcceptanceSuiteC只需要一些AcceptanceSuiteC个工件，然后可以自己生存，Commit和AcceptanceSuiteA需要：
AcceptanceSuiteB（假设这需要2分钟时间，而且我不能为了这次运行而完全孤立一个）问题是我需要能够确保：
如果我将DeploySite设置为构建配置并让DeploySite和AcceptanceSuiteA将其作为快照依赖项拉入，则AFAICT：
AcceptanceSuiteB的后续或并行运行可能会触发另一个AcceptanceSuiteB，这会破坏DeploySite和/或AcceptanceSuiteA正在使用的部署。虽然我可以说限制同时运行的版本的数量以强制一次只发生一次，但我需要一次只有一个和而不是依赖件仍在运行。
TeamCity中有没有办法对这样的层次结构进行建模？
编辑：想法： -
废话解决方案是AcceptanceSuiteB可以设置'使用中标志'标记，然后让DeploySite配置清除[AcceptanceTests和AcceptanceSuiteA之后的标记]。然后问题变成让管道下一个AcceptanceSuiteB等待，直到再次打开所述门（在构建中进行阻塞等待，感觉不对 - 我希望它被标记为'尚未启动'而不是看起来花了很长时间做某事）。然而，这种东西在这里有一个标志并且有点检查它是我试图摆脱的那种可变的状态/片状气味。
编辑2：如果我可以通过编程方式更改代理配置，我可以将Agent Requirements设置为要求 InUse = false ，然后在部署启动时设置标志并在测试后清除它已经运行
答案 0 :(得分：3)
似乎您先查看Jetbrains Devnet和YouTrack tracker，并记住在搜索中使用魔术字clobber。
然后安装groovy-plug并使用StartBuildPrecondition工具
要使用此功能，请添加system.locks.readLock。或system.locks.writeLock。属性到构建配置。 只有在没有使用同名的读或写锁运行的构建时，才会启动使用writeLock的构建。 只有在没有使用相同名称的写锁运行的构建时，才会启动使用readLock的构建。
其中管理依赖配置'read'和DeploySite config'写'共享项的事实。
（这不是一个完整的产品化解决方案，因此跟踪器项目保持打开状态）
编辑：我还不知道锁是否应该在构建参数|系统属性下以及完全名称格式应该是什么，是{{1} （即，在配置中显示参考语法locks.writeLock.MYLOCKNAME）？
其他益智游戏是：如何管理由writeLock任务读取访问的构建完成触发的构建 - 锁定是否被丢弃直到下一个读取（这将允许另一个写入者） - 或者是否有必要什么东西同时排队父母和子女的依赖？