tags:

views:

605

answers:

1

I've seen the post about disabling work item creation on all failed builds, but I'd like to have TFS only create a work item on the first failure. We have a very complicated legacy system that involves VB6 COM components and frequently have build failures on the build server that track back to some funkiness VB6 does with binary files (frx, ctl, etc. -- if you haven't had to deal with that in a while, you don't want to). The only way to resolve those issues is to try to make updates on a developer machine, then check in the files and run the build again (since the build doesn't fail on the dev machine). So we may have three or four (or more) failed builds before we get a success, which means we'll have three or four work items to close out.

Ideally, I'd like to have the following:

  1. Joe checks in a change that causes the build to fail
  2. A work item gets created and assigned to Joe
  3. Joe checks in another change and the build still fails
  4. No additional work item creation
  5. Joe checks in a change the build succeeds
  6. The work item assigned to Joe in step 2 above gets marked as Closed

But I'd be happy with just steps 1 through 4.

+1  A: 

How would you determine that the second failed build was related to the first one, since there's an additional check-in involved? What happens if the next check-in is actually additional code committed by another developer - you'd want them to know their code broke the build, or that it's still broken, even though according to your steps, nothing would be triggered.

You'd either need to find a way to link the builds - for example, track who the auto-work-item is assigned to and then not create another work-item for checkins from that developer until there's a successful build, and maybe you could somehow queue up the builds for the other developers. I'm not really sure how you'd do it.

Does this move you in the right direction?

rwmnau
Sorry. There is an underlying assumption that nobody else commits code until the build succeeds unless they're committing to fix the build. So any subsequent commits that still result in a broken build should not get a "fix the broken build" work item in TFS.
David W
No worries, then - that's actually easier (as long as the assumption holds). If the build process fails, it sends out a notice, and then no other notices are sent out until a build succeeds, when the process is reset and another failed build results in a new notice. Make sense?
rwmnau