How to change Partially Succeeded build to Succeeded in TFS 2010

Question

So I found the post "Best way to force the build status from partially succeeded to succeeded?" which is similar to what I'm looking for, but the suggested answer says to use a GetBuildProperties activity to refresh the build status (which I can't find in TFS 2010, so I'm guessing it is specific to TFS 2008?), and then update it using a SetBuildProperties activity.  Also, it is dealing with the case of unit tests failing, which I am not concerned with.

So in my scenario both the compilation of code and the running of tests will pass, and I mark them as Succeeded on the BuildDetail object using the SetBuildProperties activity, and all is good.  After that though I go on to deploy changes to a database from our TF Database project using MSBuild.  Occasionally the deploy will timeout and fail (which is a separate issue on its own), and MSBuild writes the error to the build log.  However, as a work-around I catch the specific exception and simply try deploying to the database again, which typically works the second time around.  So the BuildDetail.CompilationStatus and BuildDetail.TestStatus are both still set to Succeeded, but when the build completes it is marked as Partially Succeeded (I'm guessing because a Build Error was written to the log files).

I've read this post which explains how TFS chooses the final build status, so my thoughts were that the BuildDetail.Status was being changed to PartiallySucceeded after the DB deploy timeout, and that I could simply change it back to what it was before the database deployment, but when I inspect this property during the build it is ALWAYS set to InProgress; before the DB deployment, and after it whether the timeout occurs or not.

So how can I have our builds show as Succeeded when code compiles, all tests pass, and I run into this timeout issue and catch it and rectify it?  Our build process also does several other things, such as publish web services and whatnot, so I don't want to just blindly mark the build as Succeeded every time I rectify the timeout issue, since I still want the build to show as PartiallySucceeded if one of these other operations fail.

This is a problem because every time a build finishes as Partially Succeeded, the QA team needs me to look at the logs to let them know if something really did go wrong, or if it was just a timeout issue and we had to deploy to the database a second time and that build really is good to use.

Any advice or suggestions are appreciated.  Thanks in advance!

---

- Dan - "Can't never could do anything"

Answer 1

Hi Dan,

Thank you for your question.

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

Thank you for your understanding and support.

Best regards,

---

Lily Wu [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Dan,

In the build marked "partially succeeded," do you see any error nodes (red circle with an 'x')? The last piece of logic used to determine the status of a build automatically is to see if any extraneous build errors occurred in the process itself -- if we find some, we will alter the status to partially succeeded. Keep in mind that we will not change the final build status if you set it to something explicitly yourself in the build process.

Patrick

Answer 3

Hi Patrick, thanks for the reply.  Yes, when the database deployment fails I do see error nodes in the build log.  I guess it's good to know that if I manually set the BuildDetail's Status to Succeeded then it will pass.  However, this still doesn't resolve the issue of what if there are other "extraneous build errors" somewhere else in the build script; I still want to know about them and have the build show as Partially Succeeded if they occur so that we don't always have to have a technical person review the build log to verify that everything did go properly.

So I see two problem scenarios with me just explicitly setting the Status to Succeeded manually:

Scenario 1 - an error (non-compile and non-test related) occurs before my database deployment code.  There's no way for me to check that this error occurred (since the build Status is always marked as In Progress during the build), so if I just update it to Succeeded then the build will not show Partially Succeeded as it should, and I won't know that a problem actually occurred without still having to manually open the build logs.

This scenario would be fixed if there is a way for me to check weather an "extraneous build error" has already occurred before doing the database deployment, as if there already was an error I would simply not change the build Status to Succeeded after the database deployment completes.  Is there a field that I can check for this?

Scenario 2 - an error occurs after my database deployment code.  If I've already explicitly marked the build Status as Succeeded and then an error occurs after, will the final build status get flipped back to Partially Succeeded?  From your reply above it sounds like the answer is no.  Do you know if this will be changed in VS11/TFS11?

Any help or suggestions you have would be greatly appreciated.  Thanks Patrick!

---

- Dan - "Can't never could do anything"

Answer 4

Thanks Patrick for the comments.

Dan,

We ran into similar issue in our environment. One of the differences is team would like to mark the build as Failed, if the build status is PartiallySucceeded.

Since the build would be marked as “PartiallySucceeded” for many reasons (we also do deployment, smoke test and whatnot..), I ended up creating a custom build template to achieve this, I used CompesableActivity to check the build status and mark it failed, if the builddetail.status is PartiallySucceeded.

Here is snippet of Workflow

---

Regards,
Adhi
My TFS Blog
Please remember to mark as answered, if this reply helps

Answer 5

Hi Adhi, thanks for the reply.  Yeah, one of my main problems is that I didn't have any way to check if the BuildDetail.Status was PartiallySucceeded or not; it was always marked as InProgress throughout the whole build process.  It looks like you were able to get around this though by doing the check outside of the Run On Agent activity.  Is this CompesableActivity a custom activity that you wrote? I don't see it in the Toolbox.  If it is a custom activity I suppose I could maybe use a Try-Catch-Finally to do the same thing.  I'll give that a shot.  Thanks!

-- Edit: I just found the CompensableActivity under the Transaction node in the toolbox.  I'll give it a try.  Thanks again! --

---

- Dan - "Can't never could do anything"

Answer 6

So thinking about this a little more, this still won't solve my problem.  It works for you because you want to fail the build on a PartiallySucceeded, but because I want to Succeed the build I have to be more careful.  My initial thought was that I would just have a flag that I could check to tell me whether or not the database deployment problem occurred, and if so I would flip the build to Succeeded.  However, I still have the problem where I don't want to flip it to Succeeded if some other build problem occurred, and unless there is a way for me to check what the actual build errors that got logged were, I can't know if my database deploy error was the only one or not.  So while this does get me a little closer to my goal, I'm still not there yet.

Thanks for the feedback though, and any other suggestions are appreciated :)

---

- Dan - "Can't never could do anything"

Answer 7

Dan,

That makes sense.

Since you want to ignore the deployment error, catch all exceptions on your custom msbuild task and log the error as normal message, because logging the error as warning or error would fail/error the build, which would become partially succeeded.

---

Regards,
Adhi
My TFS Blog
Please remember to mark as answered, if this reply helps

Answer 8

No, we just use the built-in MSBuild activity to do the deploy (through command-line arguments), so I can't intercept the error message before it is written to the logs :(

---

- Dan - "Can't never could do anything"

Answer 9

Hi Adhi.  This would definitely be a solution, but I'm not sure how to specifically implement it.  I don't see any properties on the MSBuild Activity that allow me to intercept or change the errors that it writes to the TFS Build log.  I've already got the MSBuild Activity wrapped in a try-catch to handle the database deployment exception, but that doesn't prevent the MSBuild Activity from writing an error to the TFS Build log.  How would I go about catching exceptions from the MSBuild activity before they get logged?  Thanks.

---

- Dan - "Can't never could do anything"

Answer 10

From a support perspective this is really beyond what we can do here in the forums. If you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:  http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone.

---

Trevor Hancock (Microsoft)
Please remember to "Mark As Answer" the replies that help.

Answer 11

Hi Patrick, so just to be clear, there's no way for us to examine those extraneous build errors to see their details?  Thanks.

---

- Dan - "Can't never could do anything"

Answer 12

Dan,

Did you get a solution for this issue? I'm having a simillar situation, trying to change the status of the build if it completes partially succeeded.

Regards

Aravind

Answer 13

No, Adhi's solution above will work if you need to Fail the build if it partially succeeds, but not if you want to change the build status back to Succeeded with any sort of certainty about what caused the build to be marked as Partially Succeeded in the first place.

---

- Dan - "Can't never could do anything"

Answer 14

Thanks for the info!!! Let us know if you get any solution for this issue.

Regards

Aravind

Answer 15

Hi,

Did you try below solution?

you could wrap the msbuild.exe into a custom activity and put it into a try/catch block. use msbuild.exe wrapper only for database deployment...

catch the timout exception and don't write build error...however if any other error appears write "writebuilderror"

Thanks,

Mayank

---

Mayank Goswami

Answer 16

Hmmm, I hadn't thought of wrapping up MSBuild into my own custom activity; I've always just used the built-in activity.  Once I find some time I'll give it a try and let you know how it goes.  Thanks for the suggestion!

---

- Dan - "Can't never could do anything"