Build Trigger Management in Team Foundation Build 2010

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.

imageWhat 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.



7 Replies to “Build Trigger Management in Team Foundation Build 2010”

  1. It would be great if we could trigger a build upon another successful build. For example, we have a mobile app that we want to build every time there is a successful framework build or there is a checkin to the Mobile folder. How can we trigger the Mobile build when the Framework build (has separate build definition) has succeeded?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s