7

我在相应的文件夹中有两个解决方案，例如

  1. SolutionA\SolutionsA.sln
  2. SolutionB\SolutionB.sln

每个解决方案都配置了 Gated Check-in 构建；即两个构建定义GatedSolutionA 和GatedSolutionB。

现在的情况是，如果我同时检查两个文件夹中的更改，TFS 会显示一个对话框来选择构建（使用 GatedSolutionA、GatedSolutionB 下拉）以针对更改集运行。我的变更集在解决方案 B 中有重大更改，在解决方案 A 中有非重大更改。即构建 GatedSolutionB 会失败，但 GatedSolutionA 会通过。

当我选择 GatedSolutionA 来针对我的变更集进行构建时，TFS 将其签入，这反过来使解决方案 B 处于损坏状态，并且解决方案 B 的门控签入目的被破坏。

如果我将触发器更改为 CI 以进行构建定义，TFS 会将两个构建都排入队列。

我正在寻找的是相同的行为，即所有门控构建都排队，如果其中一个失败，变更集应该被拒绝。

注意：我不想为这两种解决方案创建单个构建定义。另外，我知道我们可以通过创建两个单独的变更集来避免这个问题的发生，但这通常发生在开发人员不知道他们有一些文件正在签入以寻求解决方案而不是他们正在处理的解决方案时。

2019 年更新

由于 TFS 和 Azure DevOps 已经开始使用 GIT 和拉取请求 - 使用分支策略（在主分支上），因此可以添加多个构建检查，例如路径更改SolutionA\*，BuildA 可以配置为排队和检查，类似地更改path SolutionB\*， BuildB 可以配置为排队和检查，因此对于在两个路径中都有更改的提交，将对两个构建进行排队以进行检查。等待使用 GIT 是值得的。

分支策略：https ://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation

注意：文档未更新以显示路径过滤器，并且在https://github.com/MicrosoftDocs/vsts-docs/issues/3235的 github 上提出了缺陷。因此，筛选器在 Azure DevOps 和服务器中可用。

4

4 回答 4

3

@Gchaves found a solution for that problem, you can go to "Edit Build Definitions" and on "Workspace" tab if you configure your "Source Control Folder" to the inner folder, where you have SolutionA.

For instance, if you have this file system:

  1. Projects\SolutionA\SolutionA.sln
  2. Projects\SolutionB\SolutionB.sln

Now if you configure "Source Control Folder" and "Build Agent Folder" to Projects\SolutionA, the Gated check-in will only be triggered when you try to checkIn SolutionA, and it will only compile SolutionA.sln (for this to be true you must have to point just to SolutionA.sln on Process Tab ->1.Required->ProjectsToBuild)

And then you can have multiple solutions under same workspace, building, checking in and labeling independently:)

于 2011-09-29T10:50:54.967 回答
1

在 Process 选项卡的构建定义中，您可以选择一个以上的 sln 来构建。

于 2011-06-14T08:39:00.997 回答
0

此问题的一种解决方案是让开发人员为单独的解决方案映射单独的工作空间。如果解决方案之间没有代码重叠，并且您试图阻止开发人员在构建另一个解决方案时检查一个解决方案，那么他们应该使用不同的工作区。

如果您有解决方案A 的工作区A 和解决方案B 的工作区B，则待定更改对话框将仅显示对相应工作区所做的更改。

正如您所说，您知道可以通过使用单独的变更集来避免它。这就是您可能“强制”开发人员使用两个单独的变更集并避免“开发人员不知道......”情况的方式。

为他们创建工作区并撤销他们的“创建工作区”权限，这样他们就不能创建一个包含这两个区域的工作区。

于 2011-07-20T21:17:05.833 回答
0

我知道您说过您“不想为这两种解决方案创建单个构建定义”，但这实际上是您在这里唯一可行的选择。我建议有两个分支，一个用于功能开发，一个用于集成。让您的开发人员在功能分支中工作，并为这些解决方案使用门控签入（或 CI）构建。定期将功能分支中的更改合并到一个集成分支中，该集成分支具有一个构建所有解决方案的门控签入构建定义。这将使您的集成分支的构建保持干净。

于 2011-12-19T14:59:12.837 回答