Even though Visual Studio 2010 has been out for some time, I encountered an interesting question on a discussion list recently. The question was basically, “What happens if I check into a folder which is mapped to a Gated and a CI build?” I didn’t know the answer off hand (I’m not sold on Gated Check-in builds, but that’s worthy of its own blog post) so I did a bit of testing. Before I could start another question came up which was, “What happens if I check into a folder which is mapped to multiple CI builds?”. That one I did know, but I think it’s worth covering these questions and a few others in more detail.
Gated Check-In (GC) vs. Continuous Integration (CI) Builds
If you have GC and CI builds mapped to the same Source Control folders, a check-in to those folders will only trigger the GC build. When the GC build completes successfully, it will check in the changes with the special ***NO_CI*** comment to prevent any CI builds being triggered.
Note, if a user decides to override a GC build, the check-in will trigger the CI build(s) unless they enter ***NO_CI*** somewhere in the check-in comment.
What if you want to use the power of gated check-in to protect your source code repository, but then run CI builds as a result? For example you may configure a fast GC build to perform an incremental get and run a subset of tests to validate the check-in. If the GC build completes successfully you want to move to the CI level of builds. Fortunately there is a way to do this. You need to edit the SyncWorkspace activity in the build template and set NoCIOption="false" on it. Once that is set, your GC build will check-in without the ***NO_CI*** comment and your CI builds will trigger after the GC build completes successfully. (thanks to William Bartholomew for the tip)
CI Builds vs. CI Builds
So what happens when a folder is mapped to multiple CI builds. In this case multiple builds are triggered. This is by design as it’s perfectly valid for these builds to be performing different operations on the code base. These builds will be queued and handled by your controller / agent configuration independently.
GC Builds vs. GC Builds
Finally, if you have multiple GC Builds configured to the same folder(s), you will be presented with an option of choosing which GC Build to trigger.
I think that covers all the scenarios and I hope that gives you a better understanding of the build triggers in Team Foundation Build 2010.