Orcas SP1 TFS Build Changes

  • Article

Brian Harry put up a post on the improvements that will be available in the upcoming Team Foundation Server 2008 SP1 release.  Here's some more in depth info on two of the TFS Build changes:

1. Conditionalize builds on the trigger.

There are actually a few changes here...  Essentially we exposed a property on IBuildDetail called Reason that tells you why the build was started.  Reason is an enum of type BuildReason, and can have the following values:

  • Manual.  This indicates that the build was manually started (e.g. by a user through the Queue Build dialog).
  • IndividualCI.  This indicates that the build was started due to a checkin, and that it's build definition is set up to build on each checkin.
  • BatchedCI.  This indicates the the build was started due to one or more checkins, and that it's build definition is set up to accumulate checkins.
  • Schedule.  This indicates that the build was started due to the time, and that it's build definition is set up to build on a regular schedule if changes have occurred.
  • ScheduleForced.  This indicates that the build was started due to the time, and that it's build definition is set up to build on a regular schedule whether or not changes have occurred.

In addition to exposing this new property on IBuildDetail, we have also exposed it as an output property of the GetBuildDetails task and as an MSBuild property available in your TfsBuild.proj files.  This could be useful in a couple situations:

  • You can use it to detect whether a build of an individual definition is running as a result of being triggered by the system or as a result of being started manually by a user.  It may be useful to distinguish these two cases and set various properties to different default values, etc.
  • When pointing more than one build definition at the same TfsBuild.proj file (e.g. so that you can use the same script for your CI build and your Nightly build) you can use it to detect which build definition a particular build is for.  Again, it may be useful to distinguish these two cases.

For example, if you only wanted to generate a custom build number for your nightly build, you could do something like this:

   <Target Name="BuildNumberOverrideTarget" Condition=" '$(Reason)' == 'Schedule' ">
    <MyBuildNumberGenerator TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)">
      <Output TaskParameter="BuildNumber" PropertyName="BuildNumber" />
    </MyBuildNumberGenerator>
  </Target>

2. Reduce build log noise.

In Orcas RTM, we tried to reduce the dependency of TFS Build on the names of particular targets, tasks, events, etc. in MSBuild.  The goal was to make it more usable by people who wanted to radically customize their build process, and in general I think we did a pretty good job here.  Unfortunately, one side effect of the associated changes was the presence of lots of "noise" build steps in the Build Details dialog.  In particular, each project-to-project reference resulted in three build steps of the form:

  • Project 'project' is building project 'dependent project' for targets 'GetTargetPath'.
  • Project 'project' is building project 'dependent project' for targets 'GetNativeManifest'.
  • Project 'project' is building project 'dependent project' for targets 'GetCopyToOutputDirectoryItems'.

These build steps should all magically disappear when Orcas SP1 is installed. 

To accomplish this, we added a property called TargetsNotLogged to the TFS Build targets file that specifies the target names for which build steps should not be added when our logger receives ProjectStarted events, and made the default value of this property 'GetTargetPath;GetNativeManifest;GetCopyToOutputDirectoryItems'.  If you want these build steps back, just set the property to the empty string in your TfsBuild.proj file.  If you want to exclude other targets as well, just set the property to your desired semicolon-delimited list of excluded targets in your TfsBuild.proj file.

(NOTE: I modified the above text on 12/30/2008 to make it more clear that the TargetsNotLogged property should be modified by overriding the default in your TfsBuild.proj file(s), not by modifying it in place in the TFS Build targets file.)

Next week I'll post on Detect test result and/or Dynamically created properties.