Question

I have two solutions in their corresponding folder e.g.

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

Each solution has Gated Check-in build configured; i.e. two build definitions GatedSolutionA and GatedSolutionB.

Now the situation is, if I check in changes in both folders together TFS shows a dialog box to select build (drop down with GatedSolutionA, GatedSolutionB) to run against the changeset. My changeset has breaking changes in solution B and non-breaking changes in Solution A. i.e. Build GatedSolutionB would fail but GatedSolutionA would pass.

When I select GatedSolutionA to build against my changeset, TFS checks it in, which in turn leaves the solution B in broken state and purpose of Gated check-in is defeated for Solution B.

If I change the trigger to CI for build definitions, TFS queues both builds.

What I am looking for is same behaviour i.e. All the Gated builds are queued and if one of them fails, changeset should be rejected.

Note: I don’t want to create single build definition for both the solutions. Also, I know we can avoid this problem to happen by creating two separate changesets, but this is generally happening when developers are not aware that they have some files being checked in for solution other than they are working on .

Update 2019

Since TFS and Azure DevOps have started using GIT and Pull request – using branch policies (on master branch) one can add more than one build checks e.g. for changes in path SolutionA\*, BuildA can be configured to be queued and checked, and similarly for changes in path SolutionB\*, BuildB can be configured to be queued and checked, and consequently for a commit having changes in both paths will queue both the builds for checking. Wait for using GIT was worth it.

Branch Policies: https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation

Note: documentation is not updated to show the path filter, and defect is raised on github here https://github.com/MicrosoftDocs/vsts-docs/issues/3235. As such the filter is available in Azure DevOps and Server.

Answer 1

I know that you said that you “don’t want to create single build definition for both the solutions,” but that’s really you’re only viable option here. What I’d suggest is having two branches, one for feature development and one for integration. Have your developers work in the feature branch(es) and use gated check-in (or CI) builds for those solutions. Periodically merge the changes in the feature branch(es) into an integration branch that has a single gated check-in build definition that builds all of your solutions. That will keep the builds from your integration branch clean.