Thanks for the response. Just so that you know I am actually making the build completely fail (not partially failed) on any of the tests failure. The way I am doing this is setting up the
<TreatTestFailureAsBuildFailure>true</TreatTestFailureAsBuildFailure>This is TFS 2008 SP1 feature and I am assuming this should bypass/fail gated checkin step? However the buddy build still checks in the code although the build gets failed.
I have a couple of more queries:
- Firstly, I have come across a problem. Lets say I checked out a file in my visual studio solution, made some changes to it and then ran the buddy build, which in turn checks-in the file on successful build. At this stage, when I looked at my file in the solution in visual studio solution explorer/tfs source control explorer, the file still appears to be checked out. And if i make further changes to it and re-run the buddy build, then it comes up with the policy errors that "the file is in conflict state"? I do not understand why would it say that? And if I further force the build to run, it gets failed on "Getting Source" step and after that it goes into a limbo state and keeps getting failed at the same "Getting Source" step no matter I do get latest or revert the file back to the previous version. I end up creating a brand new build definition. On the other hand, if I do get latest on the solution, before making any changes to the file, then the buddy build does not comes up with any conflict error and runs fine. But i don't see any point of doing get latest after running buddy build each time.
- Secondly if I want my developers to use gated checkin feature via buddy build, then Does it mean they should never use the standard tfs checkin feature (right clicking the file and check in the file)? Because that would put the changes in the source control without any validation?
Awaiting
Nabeel