7

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.

scorpio
  • 1,587
  • 2
  • 15
  • 27
  • May I ask why you don't want to create one build definition for both solutions? It really seems to me the only solution here. – Duat Le Jun 14 '11 at 04:59
  • We have CI builds for each solution. One developer should work in one solution at one point of time. I have faced this error when developer checks in changes which are not intended to be checked in, as you may be aware that from visual studio if you check in changes from solution explorer it includes all the files by default – scorpio Jun 14 '11 at 08:02
  • Sorry but I'm still not sure if you answer my question. You can have multiple CI build definitions, but can you have one Gated-checkin build definition for both solutions? – Duat Le Jun 14 '11 at 11:02
  • Duat the scenaio is explained in small set, in real world I have around 100 solutions. And in fact what I explained can be used as hack to break any build. – scorpio Jun 14 '11 at 12:00

4 Answers4

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

CJBS
  • 15,147
  • 6
  • 86
  • 135
Vando
  • 179
  • 3
  • 9
1

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

Adiel
  • 55
  • 1
  • 7
0

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.

Swoogan
  • 5,298
  • 5
  • 35
  • 47
0

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.

Jim Lamb
  • 25,355
  • 6
  • 42
  • 48