I've recently discovered the "hidden feature" of TFS that allows you to prevent a CI build from kicking off if your comment contains ***NO_CI***.
I have TFS running at home and this works little trick works like a charm.
At work we are also using TFS 2010. I'm finding that this still does not prevent CI builds from kicking off in our setup.
My question is, what process actually checks to see if ***NO_CI*** exists in the comment to determine whether or not to block the CI build? My initial thought was to look at the build template. I didn't see anything too obvious. Has anyone ran into this? Can you point me in the right direction?
Basically, when a checkin occurs, the AT will intercept and fire an event to notify the build component about the checkin. The build component then takes the appropriate action per the trigger type (continuous integration, rolling build, scheduled build, gated-checkin, etc.) of the affected build definitions.
If your checkin comments do contain the string ***NO_CI***, but the changesets still trigger the CI builds, look at the event log(s) on the AT(s) and see if there is any warning with the message "TF215041: Failed to process changeset n".
If your team uses gated checkin build definition, make sure they didn't choose to disable the ***NO_CI*** comment from the build template to allow a gated checkin changeset to trigger CI.
This issue turned out to be a mistake on my end. After my build succeeds I have a couple of automatic check-ins submitted. The first one included ***NO_CI*** and the second didn't. I had not realized the second check-in was being made into a path that a second build had mapped in it's workspace. Thus, the first check-in wasn't causing the CI build to kick off, it was the second check-in.
