Changsets in the build process

Changsets in the build process

• sachinsharma

  Hi Michael

  You can disable getting a list of changesets by setting the <skippostbuild> property in Microsoft.TeamFoundation.Build.targets file to 'True'. By default this is set to 'False'. However please note that a limitation with this is that if you choose to skip getting chnagesets - the associated work items also wont get updated as we do this using the same MSBuild task.

  Another point to note - by updating the property value you would only not get lists of changesets for successful builds. To also make sure that you dont get this list for failed builds please make sure that the Target in this file called 'GetChangesetsOnBuildBreak' is not executed . You can do this by modifying this line as follows in the targets file (the condition in italics and bold is what I have added).

  Hope this helps

  Thanks

  -Khushboo

  <!-- Override this target to plugin custom tasks after BuildBreak target -->

  <Target Name="AfterOnBuildBreak" />

  <Target Name="GetChangeSetsOnBuildBreak"

  Condition=" '$(SkipPostBuild)'!='true'and

  '$(IsDesktopBuild)'!='true' " >

   

  
  
  

• Drudkh

  Could something similar be done to exclude getting the changesets on build break, but still allow them to happen on a successful build

  The reason I ask is for this scenario.
  I check in my changeset with comments that I fixed a bug.
  The build process fails in another area, but
  the build report shows my changeset noting the bug fix. (Can the bug be fixed in this build since the build failed )
  Fix the problem that caused the failure and rebuild -- now the successful build has no notes about my bug fix.
  Anyone looking for these comments would have to actually look at the failed build.

  It would be nice to not gather the changesets on a failed build, and still show up in the next successful build.

  Thanks for your thoughts.
  --MikeH

  
  

• kenjioba

  Actually this scenario is already taken care of in the build process.

  For successful build, by default, we do two things (this is GetChangeSetsAndUpdateWorkItems target that run as a post build step) -

  1. Gather list of changesets gone in this build and workitems associated/resolved with these changesets.
  2. Update the FixedIn field of these workitems with this build number

  However, for failed build we skip #2 above (we run GetChangeSetsOnBuildBreak target which does not update workitems).  Hence the work items are not stamped with failed build.

  Note that the #1 above gathers the list of changesets since last "good" build where a "good" build means compilation and test run are success.  So, in your scenario, once you fix the build break, the bug will appear properly in the next build.

  And as Khushboo said, you can customize GetChangeSetsOnBuildBreak target.  This will not have any effect on passed build.

  Thanks,

  Gautam

  
  
• Changsets in the build process