Sorry for the delayed reply.
So, I was able to perform some testing to figure out why breaking the build upon test failure was not preventing the checkin from occurring, and I found out the following:
- When tests fail during a build, Team Build 2008 sets the TestSuccess property to false. However, the Buddy Build infrastructure, i.e. the BuddyBuildExtensions.targets script, does not use that property. It only evaluates the BuildBreak property, which is the one set to true by Team Build upon failure in compilation. Now rather than going and changing BuddyBuildExtensions.targets so that it takes into consideration the TestSuccess property, I suggest doing the following:
- Override the AfterTestConfiguration target that Team Build 2008 furnishes for you, like so:
<Target Name="AfterTestConfiguration">
<PropertyGroup Condition=" '$(TestSuccess)' != 'true' ">
<BuildBreak>true</BuildBreak>
</PropertyGroup>
</Target>
-
- This way you force BuildBreak to be true whenever TestSuccess is not true.
As for the other two questions:
- When you queue a gated checkin using the Buddy Build tool, you are given the option of shelving the changes removing the local changes. If you choose to keep the local changes in your workspace, when the build succeeds and checks in, this will create a new version in TFS for those particular files. Now since you still have pending changes against the files in your workspace, and since your base version is not the latest version in TFS anymore (since there was a checkin), you will need to reconcile the changes. So, when you perform a get, TFS will notice the discrepency and offer you to resolve it using the conflict resolution tool (the merge tool). In this case, if you haven't made any other changes to those files after you've queued the build, then you should take the server changes. If you've made any changes locally after queuing, then you will need to probably merge the changes visually using the merge tool. This is the same case with the built in gated checkin tool when you use TFS 2010. However, in TFS 2010, when the build finishes and checks in, you will be notified and presented with the option of reconciling the changes. As for your scenario, if you force a gated checkin of files in that state without resolving the conflicts in your workspace, then the build will run into the same issue. Now since the gated checkin build is designed so that it fails when it cannot resolve changes automatically (since it assumes they need manual intervention to resolve them), then it will fail the build. Now it seems from your description that it fails before that, during getting the source files. In that case, I am not sure what could be the issue unless you can share the error message(s) you see in the build log. You should not though have to create a new build definition to fix this issue. If your build is recreating the workspace whenever a build is triggered, this should fix any workspace corruption that might have happened. If not, i.e. if you are reusing the workspace between builds (like in a CI scenario where you do incremental gets), then that can cause issues. In fact, you should try and avoid running gated checkins against CI build definitions or ones that perform incremental gets or incremental builds.
- For your second question, the answer is: it depends. Gated checkins are not suitable for each and every scenario. For example, if your build takes more than 20-30 minutes, then gated checkins can probably hurt you more than they would help you. Typically, you would want to restrict the usage of gated checkins to build definitions that are short and sweet. Another scenario where they can be useful is for integrations (merges) from one branch to another, where for example you don't want the merged files committed unless they pass your test suite. In that case, gated checkins are ideal.