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

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

Ohad Oron — Wed, 01 Aug 2007 09:27:20 GMT

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?

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

buckh — Wed, 01 Aug 2007 16:26:52 GMT

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

VSTS Links - 08/02/2007

Team System News — Thu, 02 Aug 2007 17:59:10 GMT

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

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

StevenIBSI — Tue, 28 Aug 2007 01:41:54 GMT

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

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

buckh — Tue, 28 Aug 2007 02:54:07 GMT

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

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

StevenIBSI — Wed, 29 Aug 2007 00:30:30 GMT

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

</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

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

buckh — Wed, 29 Aug 2007 01:45:31 GMT

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

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

StevenIBSI — Wed, 29 Aug 2007 17:58:03 GMT

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

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

buckh — Thu, 30 Aug 2007 20:24:13 GMT

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

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

PaulM — Thu, 06 Sep 2007 17:31:24 GMT

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

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

buckh — Thu, 06 Sep 2007 17:40:46 GMT

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

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

PaulM — Thu, 06 Sep 2007 20:21:47 GMT

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

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

buckh — Thu, 06 Sep 2007 20:54:08 GMT

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

Did You Know You Could...?

Ravings of a Developer TS — Fri, 11 Apr 2008 00:00:20 GMT

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

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

Normal people bore me! — Thu, 17 Apr 2008 23:18:21 GMT

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

TFS 2008 CI : Scheduling Multiple fixed schedule daily builds

randy kibbe — Fri, 06 Mar 2009 22:37:24 GMT

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.

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

buckh — Tue, 10 Mar 2009 05:42:37 GMT

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

No CI Build on Check-in

Dave Lloyd's 2 Cents — Fri, 29 May 2009 05:01:41 GMT

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