Build report:Changesets taking too much time to get populated?

  • 發行項

A Team Build user had this problem the other day and I thought it would be a good idea to share this lil 'tip of the day'..

As a part of the build process in team foundation build, we report changesets associated with each build. This is done primarily to help you quickly view what all checkins that went into this build with the name of the dev who made the checkin and his comments. This makes it much simpler to point out the possible cause of a build break..

But in cases where you have a huge number of changesets being reported (say around 5k of them)..this might take several minutes hence holding up your report and build. A very typical scenario would be when you have just migrated an existing project with an already existng store of changesets and work items and you have started a build. An interesting fact which causes this is, that we report changesets only between two 'successful' builds for a team project and for a build type. Pardon me for diverting from the topic but - the definition of a 'successful' build that we use in Team Foundation Build is a "build which has 0 compilation errors and has passed all tests included in the build" (Again we had a huge debate whether test results should or should not be included in determining a 'successful' build but we finally thought that any good daily build process should have this behavior - here is what Martin Fowler says about it ( I would love hear your thoughts on this though).

Ok so back to where we were - now that you have changesets taking several minutes to report and the matter is made even worse if the builds are failing - cause everytime you have to invest the same time to even debug what went wrong with the build..here are some tips to help you..

1. Did you know that you can actually skip this step of getting changesets altogether in team build?

To do this you would need to edit the Microsoft.TeamFoundation.Build.targets file. You simply need to change the property value of SkipPostBuild to 'True'. Here is what it would look like

<!--

Set this property to true to skip PostBuild target -->

<

SkipPostBuild Condition=" '$(SkipPostBuild)'=='' " >true</SkipPostBuild>

But yes by doing this you would also be choosing to switch the automatic update of the associated work items with the changesets with the build number

2. But before even doing this - if the problem is simply that you need to debug the issue causing the build break - a better idea would be simply to do a desktop build (which does not get changesets or update work items).

Keep team building !!

Comments

  • Anonymous
    January 12, 2006
    Hi Khushboo,

    Thanx for sharing this with the rest of the community, I will give you my two cents of comments on this as my problem was a little bit different:

    - About your remark about 5k change sets, my problem was that it were a couple of changesets from which one had 5k files. This was the first build after the initial adding of a big solution, but I'm sure 5k of changesets would give the same performance 'problem'. As I e-mailed you, on our build server it took about 26 mins (to get the changesets) for about 4800 files in one changeset.

    Two other tips for 'debugging' a build:
    - When I now create a new build type (the first time for a new build type takes the longest because it will get all the change sets) I make sure the RunTest is set to false (to minimize the chances of a build error) and make sure a desktop build succeeds before I start the build on the build server. If this succeeds I enable the tests, make sure the desktop build succeeds, etc.

    - Even when a desktop build type succeeds, that is no guarantee the build on the build server builds. For example my build type failed because one of the paths (on the build server - which creates a different/longer path than locally) to my test files was longer than 260 characters.

    And I do agree with you that a successful build is a build where all the tests have succeeded.

    Best Regards,
    Peter
  • Anonymous
    January 24, 2006
    Peter,

    Please check the following posts

    https://blogs.msdn.com/manishagarwal/archive/2006/01/25/517295.aspx

    https://blogs.msdn.com/manishagarwal/archive/2006/01/25/517301.aspx

    https://blogs.msdn.com/manishagarwal/archive/2006/01/25/517315.aspx



  • Anonymous
    January 26, 2006
    Thanx, I have posted Manish my experiences on:

    https://blogs.msdn.com/manishagarwal/archive/2006/01/25/517295.aspx
  • Anonymous
    October 01, 2006
    Peter,

    I'm interested in your solution for the problem you had with your paths.
    My build type failed because the paths (on the build server - which creates a different path than locally) in my projects postbuilds events , not meet the path created on the server.