TFSBuildLab

Closed Issue: Exception when accessing Build Log [3242]

PeterBlomqvist — Tue, 14 May 2013 22:15:17 GMT

I get this exception when clicking the Build Log tab:
System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'

Can you help me out?

Closed Issue: Excessive number of StartScheduled [3243]

PeterBlomqvist — Tue, 14 May 2013 22:15:17 GMT

In the Build Events list i get a StartScheduled every minute - why is that?

Closed Issue: Problem authenticating against the TFS Server [3371]

Markl_nz — Tue, 14 May 2013 22:15:17 GMT

Hi guys - I spent some time installing TfsBuildLab, and initially had trouble getting it to work. Every time I started the service, I was getting exceptions in the event log, with the following message: "You are not authorized to access the server <tfsserver>". I thought this may have ben to do with the event registration security permissions, so I set the events up manually and turned auto event registration to false, as per the install instructions, but I continued to get exceptions logged with this same message.

I hunted through the code, and I found that in the Callista.BuildLab.Core.Tfs class, the exception was occurring because of the following code:

if (string.IsNullOrEmpty(tfsUser) && string.IsNullOrEmpty(tfsPassword))
{
_tfs = new TeamFoundationServer(tfsUri);
}
else
{
_tfs = new TeamFoundationServer(tfsUri, new NetworkCredential(tfsUser, tfsPassword));
}

In my case, I have values for both tfsUser (in the format domain\userid), and tfsPassword, as I specified these in the config file. It appeared that having the domain specified as part of the userid string does not result in the domain value being applied to the NetworkCredential in the line contained within the "else" block. In other words, because the code is not explicitly setting the domain, tfsBuildLab is trying to connect to the server using credentials which have a uid specified as "domain\username" and a blank domain string.

To resolve this issue, I believe that either the above code should use the TeamFoundationServer constructor that does not take the network credentials (this results in the thread principal's identity (i.e. the service account) credentials being used, which means that the service must be running as an account which has permission to connect to the server (as an admin??)), or the code inside the else block above should also be specifying a domain. It would be possible (and probably less complicated for configuration also) to perform a string.split on tfsUser to separate the domain out from the actual userid, otherwise I'd suggest simply including a new config setting for the user's domain, and changing the tfsUser setting to accept a uid only (without the domain specifier).

Cheers
Mark

Closed Issue: Ignore changeset entries that only have a change type of Merge [4121]

JeremyGray — Tue, 14 May 2013 22:15:16 GMT

I have two builds queued right now that don't need to be built, because TFSBuildLab triggered on the paths without accounting for the change type. Any file in a changeset that only has a change type of merge is a discard operation and would not affect the build. TFSBuildLab should ignore changeset entries that only have a change type of Merge.

Source code checked in, #94877

Project Collection Service Accounts — Mon, 01 Oct 2012 22:38:35 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #94876

Project Collection Service Accounts — Mon, 01 Oct 2012 22:31:06 GMT

Checked in by server upgrade

Source code checked in, #57274

_TFSSERVICE — Wed, 28 Jul 2010 22:13:23 GMT

Checked in by server upgrade

UPDATED WIKI: Home

MOlausson — Fri, 21 Dec 2007 09:32:36 GMT

Project Description
TFSBuildLab is a project to simplify the day to day operations when using automated builds and continuous integration with Visual Studio Team System.

This project handles common Team System issues such as:

Many of these issues are handled in the TFS 2008 release (http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/orcas-continuous-integration.xps), but for those out there using TFS 2005 TFSBuildLab is an easy way to handle build automation. We've also aimed to be as forward-compatible as possible so the features in TFSBuildLab will be very similar (conceptually atleast) to the ones in TFS 2008.

Project Documentation

Our blogs:

Mathias Olausson - http://olausson.net/blog
Peter Blomqvist - http://peterblomqvist.blogspot.com

UPDATED RELEASE: Version 1.1 (dec 20, 2007)

Thu, 20 Dec 2007 19:23:14 GMT

It's time for yet another release (probably gonna the be the last one containing any new features since TFS 2008 is out there). The next planned release will contain a tool or guidance for converting your TfsBuildLab database configuration to utilize the features available in TFS 2008.

We have been dog fooding TfsBuildLab in production since 2007-04-24 on a several projects the largest of them consisting of 5 parallel development branches each containing aproximately 10 000 source files.

Some statistics since the start:

4969 Automatic cleanups
2511 Scheduled builds
2238 Continous integration builds

*+What's new in version 1.1:+*

We have improved the errorhandling dramaically in this release as well as tried to include more contextual information in the logs.

* Service
** Added support for multiple build servers assosiaed to a trigger.
** Added support for status notifications out build completion.
** Fixed problem with to many changeset involved in build failure notifications when checkin occurs at the same time as a build is failing.

* Admin Client
** Overview of scheduled builds for a team project.
** Support for multiple reports on the dashboard.
** Add transaction support when copy config, this addresses the problem of caches becoming corrupt.

* Notification Client
** Support for notification on assignment changes to work items.
** Fixed problem with the configuration no always being persisted.

*+Upgrading from v1.0 to v1.1+*

There are no database changes in this release thus the upgrade is simple just reinstall the new version and keep the old database intact. Remever to preserver your original config files and copy them back to the installation folder again to replace the empty default configurations.

*+The release consists the follwing parts:+*

_TFSBuildLab.Server.Setup.msi_

This setup is intended to run on the application tier of your TFS installation (although this is not a requirement, this is what we are testing). If the database already exists the setup will simply skip the database parts of the setup.

_TFSBuildLab.Administration.Setup.msi_

Run this setup on any machine that needs access to administration of triggers and retention policies.

_TFSBuildLab.Developer.Setup.msi_

This setup will install both the checkin policies and the the tray icon application for build and checkin monitoring and is intended to run on the developer machines.

*+Prerequisites+*

Due to the depencies to .NET Framework 3.0 we are limited to running on either Windows XP or Windows 2003 Server (we do currently don't support Windows Vista). The service requires that a database server exists to host it's database, we currently support either SQL Server 2005 or SQL Server 2000.

Unfourtunately we are unable to upload archives including the dependencies so you'll have to take care of that on your own:

Microsoft .NET Framework 2.0 Redistributable Package
http://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en

Microsoft .NET Framework 3.0 Redistributable Package
http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

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.

Source code checked in

PeterBlomqvist — Thu, 20 Dec 2007 06:05:54 GMT

Bugfix releated to triggering scheduled builds.

Source code checked in

PeterBlomqvist — Thu, 20 Dec 2007 06:05:54 GMT

Bugfix releated to triggering scheduled builds.

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

Source code checked in

PeterBlomqvist — Wed, 19 Dec 2007 21:06:41 GMT

Forgot to update version info

Source code checked in

PeterBlomqvist — Wed, 19 Dec 2007 20:19:32 GMT

Minor changes to setup projects done * Add more error handling - FaultExceptions - Messageboxes - Tracing done * Add transactional support on CopyConfig. done * Overview of schedules for teamproject (... button on edit/add form) done * Add WIT assignment/remove notify to tray icon done * Possibility for multiple reports and one default. done * Multiple build servers support, add column to trigger and only use the workspace file if needed. done * Bugg in notification client, xml filen sparas inte vid shutdown. done * Add send email on schedule completion global setting. [CIBuildCompletionNotificationEmail] new setting in config. done * Add support for multiple buildservers. * New grid in AddTrigger dialog. * Support in for servers on the Trigger class. * Load/Save support in the db manager for triggers. * Use the collection of servers in the actual starting of a build. done * Fix problem with delayed resolvment of checkin persons * Change changeset property in QueueEntry to a list of ints. * Move get latest changeset list to before starting the build. * Assosiate the changesets with the queueentry before registering the build for notifications. * Rewrite the send notification feature to use the queue entry changesets.

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?

Source code checked in

PeterBlomqvist — Tue, 18 Dec 2007 22:11:48 GMT

v1.1 (Improved error handling + Switch to VS2008) Bugg: Add transactional support when copying a configuration. Bugg: Notification settings for tray icon was not alwats saved. Bugg: Sometime broken build notifications where sent to the wrong changeset commiters. New: Overview of schedules for a teamproject in the admin client. New: Notifications in tray icon client when WIT assignment changes. New: Global notification email for general build completion status. New: Support for multiple buildservers on checkin triggers.

Source code checked in

PeterBlomqvist — Fri, 07 Dec 2007 21:00:04 GMT

Fixed bug with not saving settings after adding watches in the notification client

Source code checked in

PeterBlomqvist — Mon, 03 Dec 2007 11:10:15 GMT

Fixed some glitches in the dynamic layout logic for the AddTrigger form