Welcome to MSDN Blogs Sign in | Join | Help

TFS 2008: How to check in without triggering a build when using continuous integration

If part of your build process is to check in a file, such as an updated version file, you wouldn't want that checkin to kick off another build.  You'd be stuck in an infinite loop.

To prevent that problem, simply put the string ***NO_CI*** in the checkin comment.  The code that examines a changeset to determine whether to kick off a new build will skip any changeset with that string in the comment.

[Update 07/02/2008]  If you are making a checkin as part of the build process, you can use $(NoCICheckinComment).  That property is set at run time when the build agent starts msbuild.  I had forgotten about it until a reader pointed this out.

Published Friday, July 27, 2007 8:00 AM by buckh

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: TFS 2008: How to check in without triggering a build when using continuous integration

I'm Sorry, but the method you mentioned for not triggering a build seems to be very un practicle. i think a better way to address the issue is to handle a configuration file with desired file types for triggering a build, for example .cs, .csproj, or a diffirent approach such as "listening to a specific branch - say an integration branch, and trigger a build only when something new goes in that branch. what do you think?

Wednesday, August 01, 2007 2:27 AM by Ohad Oron

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Ohad, I didn't describe how CI actually works in this post.  It works based on looking at the workspace mappings for build definitions that have CI turned on.  In other words, checkins into version control will not trigger CI builds unless they affect a build definition that has CI turned on.

In the case where you have CI enabled for a particular part of your source tree via a build definition with that part of the tree mapped and you want to check in without triggering a build, you would put the ***NO_CI*** string in your comment.

Buck

Wednesday, August 01, 2007 9:26 AM by buckh

# VSTS Links - 08/02/2007

Jeff Beehler on Watch out Tech Ed 2007 sessions. Rob Caron on Visual Studio Team System 2008 Team Foundation...

Thursday, August 02, 2007 10:59 AM by Team System News

# re: TFS 2008: How to check in without triggering a build when using continuous integration

The ***NO_CI*** trick worked well thanks.

I am using the BuildNumberOverrideTarget target with a custom build task to checkout assemblyinfo increment the build number and check it back in.  That seems to work, but my resulting dll files all have a version number that is 1 less then it should be.  

At the start of the build I see the AssemblyInfo in the working folder has the correct number and that ver gets checked into source control, but then when the Getting Sources occurs I now have the previous version of the file with a build number 1 less then what it shoould be.

Any ideas why that would be?

Thanks

--Steven

Monday, August 27, 2007 6:41 PM by StevenIBSI

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Steven, I had to think about this one for a minute, but I believe I know what's happened.  When a CI build is triggered, the system records the changeset that triggered it.  That changeset number is passed to the build as the version to use in the get.

Your process to update the assemblyinfo and check it in occurs prior to the Get.  When the get runs, it's getting the version specified by the changeset that triggered the build, which is prior to your checkin that changed the assemblyinfo, and thus the files gotten by get do not include your new change to assemblyinfo.  Likewise, the label created by the build includes what was gotten and not your newly updated assemblyinfo.

What you can do to fix this is to override the AfterGet target and simply get the latest version of the assemblyinfo file.  Then it will be included in the label and the build, giving your dlls the version number you expect.

Buck

Monday, August 27, 2007 7:54 PM by buckh

# re: TFS 2008: How to check in without triggering a build when using continuous integration

The AfterGet suggestion worked. I added the following to my build definition and now my build number and dll version numbers match.

 <Target Name="AfterGet">    

   <Get Condition=" '$(SkipGet)'!='true' " Workspace="$(WorkspaceName)" Filespec="$(AssemblyVersionInfoFile)"  Recursive="$(RecursiveGet)" Force="$(ForceGet)" />

 </Target>

I have another question/comment concerning the CI build triggers. It seemed that when I did a check-in it took about 1 minute before I saw a build in the Queued list.  And if I did multiple check-ins within that 1 minute they were all in the same build.  However if I did another check-in just a few minutes later it queued up another build.

I would like to be able to specify the number of minutes (say 10) that the CI engine would wait after the first check-in until it queued up that first build.  This way instead of only having 1 minute to get in a few check-ins I would be able to have x minutes to make multiple check-ins for that first build.  So kind of like a count down clock that starts with the first check-in after a period of inactivity.

Thanks for your help

--Steven

Tuesday, August 28, 2007 5:30 PM by StevenIBSI

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Steven, I'm glad to hear that did the trick.

The one minute delta you are seeing there is because the system checks once per minute to see if there are any new builds to queue based on checkins that have been recorded in the last minute.

The fact that all of the checkins from that minute were in the same build indicates that you had the option turned on to accumulate checkins (otherwise, you would have gotten one build queued per checkin).

I saw your other comment on the desire to have a delay before the first build.  When we designed the feature, we looked at it from the perspective that checkins tend to be more spread out through the day, so the first person checking in wouldn't want to wait some amount of time to find out how the build turned out.  Thus the first checkin kicks off a build immediately, and then the next build is kicked off no sooner than the delay time.  Having said that, I see what you are saying, and we'll consider adding it in a future release.

Buck

Tuesday, August 28, 2007 6:45 PM by buckh

# re: TFS 2008: How to check in without triggering a build when using continuous integration

So with “Accumulate check-ins” being used I as a single developer doing say three check-ins within a few minutes period would expect all three check-ins to be in the same build. But what I would get is a build for the first check-in and then the other two check-ins as part of a second build.  And configured as “Build each check-in” I would get three separate builds, even worse.

In discussions I have heard of other CI solutions they mentioned the ability to wait for a specified number of minutes of inactivity before a build would be queued.

Is there any way to configure the one minute delta to be say five minutes? At least then I would have a few minutes to do the multiple check-ins before the build would start.

-- Steven

Wednesday, August 29, 2007 10:58 AM by StevenIBSI

# re: TFS 2008: How to check in without triggering a build when using continuous integration

No, there's no way to configure a delay before the build starts in TFS 2008.  We'll add it to the feature backlog for Rosario, though.

Buck

Thursday, August 30, 2007 1:24 PM by buckh

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Does CI in TFS 2005 look at the workspace mappings for build definitions that have CI turned on. I tried checking something into a non-mapped (and even cloaked) area of Source Control, and it always kicks off a new build.

Thanks,

Paul

Thursday, September 06, 2007 10:31 AM by PaulM

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Paul, TFS 2005 didn't support CI in the box.  What CI solution have you chosen to use with TFS 2005?  Chances are whatever it is looks for the TFS CheckinEvent for a team project or something fairly high-level like that.

Buck

Thursday, September 06, 2007 10:40 AM by buckh

# re: TFS 2008: How to check in without triggering a build when using continuous integration

I followed the steps outlined here:

http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx

It sounds like I need to remove the alert I created and set one up as you described in this blog:

http://blogs.msdn.com/buckh/archive/2006/09/29/checkinevent-path-filter.aspx

Thanks,

Paul

Thursday, September 06, 2007 1:21 PM by PaulM

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Paul, that's correct.  Looking at that article, the subscription it shows would register for all checkin events on the entire server.  The checkin event filter blog post you reference is the right way to go about scoping it down to the paths you care about.

Buck

Thursday, September 06, 2007 1:54 PM by buckh

# Did You Know You Could...?

Did you know you could disable a Continuous Integration build process from firing as result of a check-in

Thursday, April 10, 2008 5:00 PM by Ravings of a Developer TS

# Altre modifiche per passare da Team Build 2005 a Team Build 2008

Altre modifiche per passare da Team Build 2005 a Team Build 2008

Thursday, April 17, 2008 4:18 PM by Normal people bore me!

# TFS 2008 CI : Scheduling Multiple fixed schedule daily builds

Buck,

   On a related subject is there anyway to setup TFS CI to build the same TFSBuild.proj multiple fixed times a day ? It seems you can only schedule it once a day. Which seems very impractical. The build takes too long for setting it up for checkin triggers.

Friday, March 06, 2009 2:37 PM by randy kibbe

# re: TFS 2008: How to check in without triggering a build when using continuous integration

Randy, there's no way to set it to trigger at multiple fixed times per day, but you can set it to accumulate checkins for CI.  That way the build won't get behind (i.e., you won't end up with multiple queued builds).

Buck

Monday, March 09, 2009 10:42 PM by buckh

# No CI Build on Check-in

Found this out just this past week. What a great tip. Thanks Colin Bowern by way of Buck Hodges Have

Thursday, May 28, 2009 10:01 PM by Dave Lloyd's 2 Cents

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker