It's all about the answers!

Ask a question

How to get build result in work item attribute


vikrant kamble (1322996) | asked Jun 13 '19, 8:56 a.m.
retagged Jun 28 '19, 1:32 p.m. by Ken Tessier (84117)

I am developing a follow up action to trigger a build when work item is in certain state, when work goes to "Deployment" state build is executed by plugin. I also want to record build results on the work item itself i.e. when build is finished executing its result pass/fail and Date should be updated on work item attribute.

 As soon as build finishes execution its result should be updated in work item attribute but we are not sure how work item would know build has finished execution and result is available. Based on application build can take 45 mins to 90 mins for complete execution.
I was thinking of creating asynchronous task which would run in background in desired time interval and updated work item but it does not seem to be proper solution because results would not be immediately updated on work item when build is finished execution but it will be executed when asynchronous task is executed.
Is there any way I can record build result on work item attribute as soon as build finishes execution.


Comments
Ralph Schoon commented Jun 13 '19, 9:45 a.m. | edited Jun 13 '19, 9:47 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The design is to have separate items for the build result and the work item. There are means to see the build results regardless if they are linked to a work item. There are ways to link build results to a work item. 


I fail to understand why users always want to push all information into one place and kill usability. All these asynchronous things create tons of work item saves killing the systems state tables, performance and the work item history. 

Who has the money to create all these extensions? What business value do they provide and to whom? What is the purpose of this? Is this in the end another of these "notify me vial e-mail" schemes.


vikrant kamble commented Jun 13 '19, 11:36 a.m.

All these asynchronous things create tons of work item saves killing the systems state tables, performance and the work item history. - This is the reason I said asynchronous task does not seem to be a proper solution


Who has the money to create all these extensions? - not our concern
What business value do they provide and to whom? -  Please tell me how to convince user who finds using RTC features is unnecessary waste of time. How do we convince business value of RTC to such audience. 
What is the purpose of this - to see the history of deployment results in work item itself because they find it easier to open a work item than looking into build result. 


vikrant kamble commented Jun 13 '19, 11:39 a.m.

 Ralph -  I would request you to delete your comment as it can give wrong impression to anyone willing to answer the question.


Sridevi Sangaiah commented Jun 14 '19, 2:51 a.m. | edited Jun 14 '19, 2:52 a.m.
JAZZ DEVELOPER

Do you use JBE for your builds?


vikrant kamble commented Jun 14 '19, 3:53 a.m.

We have integrated it with Jenkins and running build using Jenkins but build result is also available in RTC every time a build is executed via Jenkins 

One answer



permanent link
Sridevi Sangaiah (59179) | answered Jun 14 '19, 7:38 a.m.
JAZZ DEVELOPER
If you are using RTC 603 or above, you could explore using the updateworkitem ant task - https://jazz.net/help-dev/clm/index.jsp?topic=%2Fcom.ibm.team.build.doc%2Ftopics%2Fr_updateworkitem.html. This ant task is part of the Jazz Build Toolkit.

In your Jenkins build once you get past the deployment step or may be once the build is done you could use the updateworkitem ant task to post the required updates to the corresponding workitem.
 
I am not sure about the kind of association between work items and deployment builds in your setup is it like every work item is associated with it's corresponding deployment build or there is a single work item to track all deployment builds. Like Ralph mentioned it is better to avoid storing the status of all the deployment builds in a single work item.

Comments
vikrant kamble commented Jun 14 '19, 8:24 a.m. | edited Jun 14 '19, 8:25 a.m.

In our environment we run build based on application deployment as part of change request. Build result related to deployment of specific application of respective CR will go to same work item, it would give us track of application deployment result in the work item of the application of specific CR.

for multiple applications there are multiple work items recording build results respectively.


Sridevi Sangaiah commented Jun 18 '19, 12:35 a.m.
JAZZ DEVELOPER
So, a single workitem would track the status of multiple deployment build results.

Coming back to your original question of how to update the work item when the deployment is done in your builds, did you consider using the updateworkitem ant task?

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.