CI and Gated Check-in builds, working together

Question

Hi all,

I already have a CI build running on my Tfs2010 instance, but I'd like to get a Gated checkin build running as well. There are subtle differences between the ways that these two builds would run, however. Specifically, I'd like the Gated checkin to not produce bug workitems on failure, not associate changesets and workitems on build, not move builds to the drop, and not maintain previous builds. Since builds initiated by Gated checkins are uncommitted changes, these steps seem unnecessary to me, but I would definitely like my CI to perform them.

Unfortunately, there's this ***NO_CI*** thing that appears on my changesets after they're committed by the Gated Checkin build, and the CI build is never triggered. I found this thread that seemed to indicate that my DefaultTemplate.xaml should have a "Get Activity" NO_CIOption parameter in there somewhere; however nothing in the configuration file seems to indicate anything of the sort. Neither string is present, and I can't find any reference documentation in the msdn library.

In fact, in the msdn library, there's a page that seems to link to the page I want, however where the link would actually be there's a misplaced, duplicate link to "Control where the build system places your binaries." You can see the identical link directly below it.

Anyhow: how is the NO_CIOption parameter used in the build template files? Where is it placed? Has no one else besides GSS1 wanted to do this before?

Also, what's the reasoning behind disabling CI on Gated builds in the first place, anyway? Sure, it might seem wasteful to build each checkin twice, but I wouldn't think it breaks anything. If this is a possible configuration, why force the extra effort?

Answer 1

Hi,

In the build process, Process>Sequence>Check In Gated Changes for CheckInShelveset Builds>Check In Gated Changes Activity is used to check-in the Shelveset, and add "***NO_CI***" to the comment automatically, this behavior disable the CI build.

The CI build is used as BVT to make sure that the code could be build successfully, which is the same as Gated-in Build in some scenarios, so that it disables the CI build. If you want to build your source files to get a Release version, it is better to create a nightly build.

In your scenarion, if you think it is necessary to run CI build after Gated-in build,  one workaround is to subscribe the Any build completes Event using WCF/WebService, and if the build is the Gated-in Build, queue the CI build in your WCF/WebService.

You can also submit your feedback in https://connect.microsoft.com/visualstudio and our engineers will take it into consideration. Thanks for your understanding.
 

---

Best regards,
Ruiz
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg @ microsoft.com

Answer 2

I haven't quite figured out how to edit the WF for the build process yet, but once I do: are you saying that practically speaking, CI builds are only disabled if there's a "***NO_CI***" string at the end of the checkin comment? Such that if I were to disable that string manipulation during checkin, my CI build would run?

Answer 3

http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx

A good start for figuring out how to edit the WF for the build process. It should be more clear what you need to do after the first few steps.

The "***NO_CI***" string can be anywhere in the checkin comment.

Answer 4

To follow up on this, after looking through the Xaml and using reflector on the Build binaries, I found the NoCIOption property on the SyncWorkspace action. Setting this to false seems to have allowed CI builds to trigger after gated checkins, as well as removing the somewhat unsightly ***NO_CI*** checkin comment appendix.