tfsbuildlab Forum Rss Feed

NEW POST: Specify a build per source control sub-directory

PeterBlomqvist — Thu, 20 Dec 2007 19:06:21 GMT

Jason,

It seems that the issue would be a syntactical error in the trigger data (guess we could validate it but we never got around to do that) since what you are trying todo is exactly what TfsBuildLab does. If you look in the documentation around CI triggers you'll see an example like this one:

Trigger Data = \$/DEMO

It is important that you prefix the $ with a \ in other words \$ = $ this is due to the fact that the dollar sign is a keyword in RegExp. This should get your triggers working in your example you are using a | as a prefix. Let me know if this does the trick for you.

Ps. After reading it through another time it seems your problem is that the build is triggered to often? If this is the case and it still doesn't work for you after looking over the syntax in the trigger file could you please post a reply containing the branch structure of your project along with which build types you have and when they should trigger and finally the contents of the trigger table in the TfsBuildLab database.

Since what you are describing is exactly what we are doing we have several build types that correspond to various branches and the different build types are triggered based on the checkin path. Anyway let me know your config and we'll have you up and running in no time (I think ;).

/Peter

NEW POST: Specify a build per source control sub-directory

jasoncamp — Thu, 20 Dec 2007 13:22:49 GMT

I appricate your quick response. As I read back though my original question, I see that I wasn't very clear. What I am trying to do is use TFSBuildLab to initiate builds based on where the check-in was made. We have 3 builds per team project that are named development, staging and production. When I check in code to $/TeamProject1/Development, I want the development build to run. Even when I put |$/TeamProject1/Development in the TriggerPath, any check-in to $/TeamProject1 will initiate the development build. I guess I could use Benjamin Day's solution (http://blog.benday.com/archive/2007/11/19/23167.aspx), but I was wondering if I could do this with TFSBuildLab seeing as I have it installed and running in our environment.

NEW POST: Specify a build per source control sub-directory

PeterBlomqvist — Wed, 19 Dec 2007 21:51:50 GMT

Jason,

TfsBuildLab only triggers the build, it relies totally on the builddirectories specified in your build scripts (altough the release that is gonna go out on friday will let you specify a list of available build servers). The TriggerPath is the path in source control that will cause a trigger to execute once a checkin is performed in that path.

In other work the trigger path releates to the path of the items in the changeset that will cause the trigger to run and the build directory is picked up from your build script. Does this make sense.

/Peter

NEW POST: Specify a build per source control sub-directory

jasoncamp — Wed, 19 Dec 2007 20:18:00 GMT

I am unable to get the TFSBuildLab to initiate a build to a particular subdirectory. It seems that any subdirectory that I put in the TriggerPath still initiates the build for any check-ins under that team project. Is this the case?

NEW POST: Can't get CI working

jasoncamp — Fri, 30 Nov 2007 15:11:01 GMT

Nevermind, my mistake. Didn't have the user in the TFS admin group.

NEW POST: Can't get CI working

jasoncamp — Fri, 30 Nov 2007 14:18:53 GMT

I can't get CI to work. I am creating a new trigger within the TFSBuildLab admin tool and setting the TriggerPath to |$/test/development, but nothing happens. What else needs to be done? The documentation also talks a lot about a tray icon, but I don't see that either. Do I really need the | before the source code path for the TriggerPath? How can I diagnose this issue?

NEW POST: Multiple build server support/behaviour?

JeremyGray — Thu, 22 Nov 2007 15:23:43 GMT

Hey, Peter. Thanks for the quick response!

The functionality you describe as being in the current version of TFSBuildLab will certainly be sufficient, as I've already got people on-board with the caveat that there may be times when a build server is idle yet a build is queued, due to the static mapping of team build types to servers. In fact, they are more than just on-board - my peers, reports, and managers are all very very happy with the job TFSBuildLab is doing!

That said, if in a future version we were able to configure a list of usable build servers for each team build type and have the CI process feed a just-freed build machine with the oldest queued build that is configured to run on it, it would be truly awesome. Truly. I would literally have people doing high-fives, especially over on the QA team, where the current TFSBuildLab support for multiple build machines is going to be a large enough improvement but where this potential future functionality we're discussing would put the solution into an entirely different league.

NEW POST: Multiple build server support/behaviour?

PeterBlomqvist — Thu, 22 Nov 2007 12:18:29 GMT

Hi Jeremy,

Currently TfsBuildLab will just trigger builds on the buildserver specified in the BuildMachine parameter in the buildscript. Did you have anything particular in mind on how you would like it to work?

We will probably release v1.1 in a week or two with some minor updates before starting to look at a migration path to TFS 2008 for our users, our intentions are to let you just run an upgrade wizard to the built in functionality in TFS 2008.

Anyway let me know what you need and I'll see if it is something that we could accommodate easily. It would probably be rather easy to add a possiblity to list a bunch of servers along with the trigger that are to be used and just ignore what it says in the build script.

/Peter

NEW POST: Multiple build server support/behaviour?

JeremyGray — Thu, 22 Nov 2007 06:57:41 GMT

Before I get too far into messing with this tomorrow, I thought I might be well-advised to post this quick question here in case I'm just going to end up painting myself into a corner tomorrow:

I am about to clone my current build server x3 so as to introduce some parallelism into the build process. I expect that I'll be making explicit ties between team build types and specific build servers, which is sub-optimal but quite fine in my current scenario. I'll also be adding a further 3 or so build servers within a couple of weeks, each helping parallelize some other build-process-driven activities (execution of automated testing suites, to be specific.)

Is TFSBuildLab going to keep these servers busy as it is coded right now? Or does it just see a single queue of builds it needs to process one at a time?

NEW POST: Simple retention policies not working

JeremyGray — Thu, 22 Nov 2007 06:53:42 GMT

Apologies for being away so long. Things have been busy, and TfsBuildLab has been working. ;)

NEW POST: When are emails sent?

PeterBlomqvist — Fri, 02 Nov 2007 17:30:31 GMT

You are correct in your analyze, I will look into adding this to the next release (which will be very soon) it depends on how much work it would be. Most likely it would be a setting for the whole service, would this work for you? A database change at this point in time is a to large a change.

/Peter

NEW POST: When are emails sent?

amezick — Thu, 01 Nov 2007 14:35:34 GMT

After reading the code (NotificationService.cs), it looks as if the only time the smtpServerAddress is used is when a CI build fails. Is this true? Is there a way to have mail sent whenever a certain build type completes? I want to use CI builds as smoke tests (just compile the code to see if it will) and nightly builds to run the full test suite. I would like the nightly builds to always send email. Is this currently possible?

Thanks!
--Amezick

NEW POST: Problem during install

MOlausson — Wed, 31 Oct 2007 15:45:04 GMT

Good, I hope it solves your problem. Just get back to us if you have any other questions!

NEW POST: Problem during install

amezick — Wed, 31 Oct 2007 15:01:32 GMT

No, my problem was that 3.0 wasn't even installed on the tfs machine. Sorry again.

NEW POST: Problem during install

MOlausson — Tue, 30 Oct 2007 22:06:12 GMT

Did you check that .net 3.0 is installed correctly? Are you running on Windows XP SP2, Windows 2003 Server or above?

NEW POST: Problem during install

amezick — Tue, 30 Oct 2007 20:27:54 GMT

Wish I could kill this. Yup. 3.0.... sigh.

NEW POST: Problem during install

amezick — Tue, 30 Oct 2007 19:58:53 GMT

Would .NET framework 3.0 be killing this? It doesn't look like I have installed this. (argh)

NEW POST: Problem during install

amezick — Tue, 30 Oct 2007 19:43:09 GMT

I am getting this error in the event log:

I have turned on logging as describe on this site but the log remains empty. Any suggestions?

{" 10/30/2007 3:38:52 PM BuildManager failed to initialize: An exception occured ... System.Configuration.ConfigurationErrorsException: The 'system.serviceModel/services' configuration section cannot be created. The machine.config file is missing information. Verify that this configuration section is properly registered and that you have correctly spelled the section name. For Windows Communication Foundation sections, run ServiceModelReg.exe -i to fix this error.
at System.ServiceModel.Configuration.ConfigurationHelpers.UnsafeGetAssociatedSection(ContextInformation evalContext, String sectionPath)
at System.ServiceModel.Configuration.ServicesSection.UnsafeGetSection()
at System.ServiceModel.Description.ConfigLoader.LookupService(String serviceConfigurationName)
at System.ServiceModel.ServiceHostBase.ApplyConfiguration()
at System.ServiceModel.ServiceHostBase.InitializeDescription(UriSchemeKeyedCollection baseAddresses)
at System.ServiceModel.ServiceHost..ctor(Type serviceType, Uri[] baseAddresses)
at Callista.BuildLab.Core.BuildManager.OpenAdministrationService()
at Callista.BuildLab.Core.BuildManager.Initialize()
"}

NEW POST: Simple retention policies not working

PeterBlomqvist — Tue, 30 Oct 2007 19:31:02 GMT

Now I have verified the functionality in the retention policies when running in the RetentionPoliciesOnlyCleanupDropLocation mode and it works as it should as far as I can tell.

So what we can do now is a few steps:

I presume that you have performed the actual retention policy administration using the admin client? Since if you have not the problem is that the caches needs refreshing (you can do this either through the admin gui (file menu) or by restarting the service
Check the build events in the admin client, filter on the build type that you have configured and set the event type to delete you will see any deletes being performed successfully here (you will also se any potential execeptions that have been thrown here when trying to perform the delete with context :))
Turn on tracing and watch for messages containing start/stop enforcing retention policies

/Peter

NEW POST: Simple retention policies not working

PeterBlomqvist — Tue, 30 Oct 2007 07:29:30 GMT

Thanks for being so patient with the issues we are having, I promise that I'll do some more extensive tests on this scenario (as I said before we do not use it ourselfs at present). I'll try to post a fix for this or atleast an explanation before this weekend.

No promises though, since my wife have gone 2 days overtime on her pregnenacy now :) so I might be preoccupied soon... But no worries we'll have you retentions policies working soon.

/Peter

Ps. How are your retention policies setup?