Udostępnij za pośrednictwem

Orcas SP1 TFS Build Changes

  • Artykuł

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.

Comments

  • Anonymous
    May 06, 2008
    Hi Arron      Is there any performance improvement on BUILD in Orcas SP1.ThanksBalaji Dave
  • Anonymous
    May 09, 2008
    Yes, there are several performance improvements:(1) The reduced build log noise also corresponds to reduced server calls during compilation, which should speed things up a bit.(2) There were several database tweaks for SP1 (a new index, modified stored procedures, etc.) that should speed things up a bit as well.(3) Certain information nodes are now updated in bulk (in one server call) rather than individually (in multiple server calls).The amount of benefit you see from these changes will depend on the specifics of the solutions you are building, but everyone should see some performance gains.-Aaron
  • Anonymous
    May 09, 2008
    John Powell on Team Explorer Window Won't Open Or Is Blank. Alanpa on James Whittaker on software testing....
  • Anonymous
    May 12, 2008
    Team Explorer 2008 SP1: Miglioramenti nella Build
  • Anonymous
    August 25, 2008
    Hi Aaron,I have just installed TFS 2008 SP1 on our server and build machines,however I am still getting those addional build steps in our build logs ( 'GetTargetPath', 'GetNativeManifest' and 'GetCopyToOutputDirectoryItems').  Is there anything else that I have to do to our build scripts to remove these entries?Thanks,Daniel
  • Anonymous
    October 10, 2008
    Hi Aaron,After upgrading to TFS 2008+SP1 from TFS 2005 I have problems related to incorrect/corrupted tfsBuild database (in particular column Reason).Could you look at http://social.msdn.microsoft.com/Forums/en-US/tfssetup/thread/fa81ffed-4574-410e-be7f-7a86462f15fc thread and give me any ideas if possible?
  • Anonymous
    October 17, 2008
    Hi Daniel,We had the same problem, it looks like TFS SP1 doesn't update Microsoft.TeamFoundation.Build.targets on the build machines. I copied the file manually from a michine that has the latest (SP1) version, and then the additional build steps disappeared.Regards,Jan
  • Anonymous
    January 30, 2009
    The comment has been removed
  • Anonymous
    February 11, 2009
    Regarding not updating the Microsoft.TeamFoundation.Build.targets file - we experienced this and after some testing deduced that if you have previously modified the targets file, the SP1 installer will not overwrite your copy.  It doesn't warn or log or tell you about this either though!  We installed on a vanilla machine, then manually merged our changes in.
  • Anonymous
    March 11, 2010
    Could you please post configuration setting where we need to set TargetNotLogged property in TfsBuild.proj file?  I don't know where to set that property.