TFS 2010 Multiple Solutions & Build with Gated Check-in

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://docs.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.

Answer 2

@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:)

Answer 3

In build definition at Process tab you can choose more then one sln to build.

Answer 4

One solution to this problem is for the developers to have separate workspaces mapped for the separate solutions. If there is no code overlapping between the solutions and you are trying to prevent a developer from checking into one solution when they are gated building another solution, then they should be using different workspaces.

If you have WorkspaceA for SolutionA and WorkspaceB for SolutionB, then the pending changes dialog will only show changes made to the appropriate workspace.

As you say, you know you can avoid it by using separate changesets. This is how you might "force" a developer to use two separate changesets and avoid the "developers are not aware..." situation.

Create the workspaces for them and revoke their "Create a workspace" permission so that they can't make one that includes both areas.