It's all about the answers!

Ask a question

Attaching Build Results to a WorkItem

ADALARASU R S (335) | asked Jan 03 '13, 4:18 p.m.
edited Jan 04 '13, 2:48 p.m.

I m trying to find whether there is an option to create a link to a build label while creating a workitem like defect. The scenario is developers has to submit a workitem with which a deploy process has to start for an already completed build. 

My question is : Is there a way i can create a new LinkType which will help me to search the completed build labels ??


One answer

permanent link
Jan Wloka (4161) | answered Jan 04 '13, 4:37 a.m.
Hi there, 

we do support the contribution of new link types via an extension point. For details see section "Contributing a Link Type" in However, I don't completely follow your explanation. We allow for links to build results. If that's what you're looking for, you should be able to contribute a custom link type to link work items and build results.


ADALARASU R S commented Jan 04 '13, 12:35 p.m.

Thank you so much for the reply. Let me try to explain my scenario. In my organization, after the build process developers are supposed  to submit a request form to deploy the successfully built components to servers. So Developers has to submit a form ( which is actually a workitem in RTC) in which they have to provide a link to the successfully completed builds, so that deploy team will know what build they have to deploy to server.

Right now, we are able create links like "Related" which only helps to attach work items to the form, but i m not sure what kind of linktype  we have to create so that when the link is clicked it will open up a dialog box where we can search for successfully completed builds.

If i have to a create a custom LinkType for this scenario, can you please help me what type of target ItemReferenceType i have to use in the plugin ?

Ralph Schoon commented Jan 04 '13, 3:07 p.m. | edited Jan 04 '13, 3:08 p.m.

You can, from the build result in RTC, create a work item. This work item has a link back to the build result it was created from. The deployment people can access the build using this link. 

If you want to have a back link to the built data on disk you can follow . If you do, you also want to look at this article too:  

The deployment people could, that way, navigate from the work item to the build result and from the build result to that built data. Would that solve the issue?

ADALARASU R S commented Jan 04 '13, 4:16 p.m.

Hi Ralph, Thanks for the reply. I understand that we can create a work item from the build result, but when we compare that to today's world, the direction is kind of reverse . 

In clear case (We are in the process of migrating from clear case to RTC) developers used to submit a build and after the successful build they will create an component for the build then create a deploy request in which they used to refer to the component. So in RTC we thought we can handle this by just referring the build result in the deploy request form.

Problem we may face with your solution is - every successful build is not deployed to the server!, considering this scenario we may end up creating lot of unwanted workitems for all the successful builds.

Ralph Schoon commented Jan 04 '13, 4:34 p.m.

I fail to see the difference. If the build is successful and needs to be deployed, the developer creates the deployment request work item. That tracks the deployment. The Snapshot to be able to recreate the source code configuration has already been created during the build, if configured that way. 

I did not say you create the work item automatically for each build. You do that only for the ones that need to be deployed.

In addition, on the build result, you can create a release for the build. That makes the build also refer able using the release Name/ID and you can refer to it in the found in attribute of work items. This is the standard mechanism used in RTC. 

What am I missing?

ADALARASU R S commented Jan 04 '13, 5:04 p.m.

 Thank you so much for the quick response. I think we have to try this option of  associating it to a release. We will reply back to this question if that works for us.

ADALARASU R S commented Jan 07 '13, 11:39 a.m.

Hi Ralph, It may be a dumb question! can i get the "Found in" value populated from different project area ? because right now the "Build" process happens in a different project area and unfortunately all the deployment request forms (work item) are submitted from a different project area. 

Ralph Schoon commented Jan 07 '13, 12:39 p.m.

Hi Adalarasu,

I will try to have a look into that tomorrow, but I believe the release needs to be in the same project area as the work item. Let me have a look tomorrow. I will update you on the findings.

ADALARASU R S commented Jan 08 '13, 11:36 a.m.

Hi Ralph, 

Just an update I tried adding two attributes to the deploy request form and it looks like its working. Steps i followed 1) i added two fields to the form are a) Project Area(Process Area) and b) Found In (Release). 2) I modified the "Found In" Attribute to have dependency with the "Project Area".

In the form whenever i pick the Project Area, Found in gets populated with all the "Releases" of the selected Project Area. But now i have another problem, when i do the above mentioned steps, it lists down all the Associated Releases of the Build Project Area. I like to restrict the list based on the Build definition so that i can have  a smaller drop down. 

My question is do we have an attribute to list down the build definitions of a given project Area ? If we have an option to do that i can add Build definition as a dependency to the "Found In" which will help me to restrict list of the Releases.

Please let me know, Thanks

showing 5 of 8 show 3 more comments

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.