rbnijp

Hi all,

Does anyone have a good solution for the following:

When my CI builds fail, I create a new workitem and assigned it to the user trigging it off. This part works well with one issue. As the event is fired off from the TFS, the workitem gets created by the TFS service account. The service account gets stored in the read-only field "CreatedBy" at the workitem. When that user causing the failed build, resolves the issue, the service account is supposed to test the solution for the bug which obvious wont happen at all.


// Enter the work item as a bug
WorkItemType workItemType = workItemTypes["Bug"];
WorkItem workItem = new WorkItem(workItemType);
workItem.Title =
String.Format("Build {0} broken because check-in changes. Investigate and correct: {1} ", buildData.BuildNumber, changeTitle);
// Get the display name of the user
if (requestor != null && requestor.Length > 0)
{
// Code line below is not allowed !
// workItem.Fields[CoreField.CreatedBy].Value = requestor;
workItem.Fields[CoreField.AssignedTo].Value = requestor;
}
workItem.Fields[
"Microsoft.VSTS.Common.Priority"].Value = 1;
workItem.Save();


Any help is appriciated!




Re: Team Foundation Server - Build Automation Automatically create workitems with Continuous Integration

Aaron Hallberg - MSFT

See the following thread: http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=391838&SiteID=1 for one possibility. The basic idea is to connect to the TFS server as requestor rather than as the service account. Of course, this will only work if you know requestor's password... At the very least, though, you could always assign build breaks to a particular (non-service-account) user who would then be responsible for verifying the fixes.

-Aaron






Re: Team Foundation Server - Build Automation Automatically create workitems with Continuous Integration

Ognjen Bajic

Hi,

you could write custom WorkItemChanged event handler. When subscribing, filter for change of the AssignTo field and if the bug was created by your service account execute some custom logic - assign the bug to the triage role or to the release manager or whatever is appropriate.

You could also use scoping rules for the workflow definition and edit the Bug work item type definition as follows:

for the transition

<TRANSITION from="Active" to="Resolved">

in the second subelement

<FIELDS>

instead of the standard content

<FIELD refname="System.AssignedTo">
              <COPY from="field" field="System.CreatedBy" />
</FIELD>

put the following

<FIELD refname="System.AssignedTo">

    <WHEN field="System.CreatedBy" value="ServiceAccount" >

        <COPY from="value" value="Triage" />

    </WHEN>

    <WHENNOT field="System.CreatedBy" value="ServiceAccount" >

        <COPY from="field" field="System.CreatedBy" />

    </WHENNOT>

</FIELD>

 Replace ServiceAccount with the real name of yur service account. This solution can obviously assign resolved bugs to only one account but if you can live with it, it solves the problem completely.  

Ognjen, VSTS MVP