It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×12,004
×7,469
×6,111
×1,200
×562

question asked: Apr 30 '15, 2:33 p.m.
question was seen: 4,438 times
last updated: May 01 '15, 1:23 p.m.

Related questions

modifying the "Included in Build" link.

0
Sterling Ferguson-II (1.6k●13●288●273) | asked Apr 30 '15, 2:33 p.m.
CLM 502

We had a failed build, then a successful one. The work items are attached to the failed build. We have a query run against "Included in Builds". These work items are now against failed results.  My choice from the Work Item tab are Create a new work item (against the build) or Associate an existing work item (which appears as reported against the build)

How can I get the "Included in Link" created for a past build assigned to these work items.?

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Spencer Murata (2.3k●11●59●71) | answered May 01 '15, 11:42 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
It was never intended to redefine the Included in Link, since its purpose was to track the first build that included the particular work item.  If you could redefine the build that the work item is included the traceability could be compromised.  I think it could be possible to redefine the contributor with an API script, but again its not really supposed to be altered.  Why don't you want the included link to be linked to a failed build?
Comments
Sterling Ferguson-II commented May 01 '15, 12:35 p.m.

 Well, we currently send email notifying users of a new build. They log in to the link and see what work items are a part of the build so they can begin testing. (RTC-Only area). 


So we have a failed build with 10 work items, and a passing build with zero work items. So if the tester/user asks what do I need to test, or a developer asks if their work is in the latest build....

Spencer Murata commented May 01 '15, 1:23 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

So the developer will get the notification that their changes were included BUT the build failed, so they can still verify if their part of the build completed, they can fix the mistake that they made to break the build, or they can wait for the next build to verify.  The changes were accepted into the stream so all subsequent builds will include those changesets.  We only mark the first build that includes the changes, so the developer can always come back.


To switch the included link would make that logic suspect as you wouldn't be exactly sure when the changeset was introduced.  Probably the better way to approach this would be to create a task against the build to validate the deliveries in the next build.  Then you would have traceability for the developer(s) to come back later and do what they need to do and sign off that task.

~Spencer

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.