modifying the "Included in Build" link.

Sterling Ferguson-II (1.6k●8●275●268) | 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

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

It's all about the answers!

Related questions

modifying the "Included in Build" link.

One answer

Your answer