SolutionA\SolutionsA.sln
SolutionB\SolutionB.sln
现在的情况是,如果我一起检入两个文件夹中的更改,TFS会显示一个对话框来选择要针对更改集运行的构建(下拉菜单有GatedSolutionA、GatedSolutionB)。我的更改集在Solution B中有破坏性更改,在Solution A中有非破坏性更改。即构建GatedSolutionB将失败,但GatedSolutionA将通过。
当我选择GatedSolutionA来构建我的更改集时,TFS会检查它,这反过来会使Solution B处于破碎状态,并且Gated check-in的目的对于Solution B而言也失去了意义。
如果我将触发器更改为构建定义的CI,则TFS会排队两个构建。
我想要的是相同的行为,即所有Gated构建都排队,如果其中一个失败,则应拒绝更改集。
注意:我不想为两个解决方案创建单个构建定义。此外,我知道我们可以通过创建两个单独的更改集来避免发生此问题,但通常情况下,开发人员不知道他们正在为其他解决方案检查文件。
2019年更新
自从TFS和Azure DevOps开始使用GIT和Pull request - 使用分支策略(在主分支上)可以添加多个构建检查,例如对于路径SolutionA\*
中的更改,可以配置BuildA排队并进行检查,同样对于路径SolutionB\*
中的更改,可以配置BuildB排队并进行检查,因此对于具有这两个路径更改的提交将会排队这两个构建进行检查。使用GIT值得等待。
注意:文档未更新以显示路径过滤器,并且在此处提出了github缺陷https://github.com/MicrosoftDocs/vsts-docs/issues/3235。因此,该过滤器在Azure DevOps和Server中可用。