It's all about the answers!

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

×42,884
×12,011

question asked: Oct 12 '12, 11:01 p.m.
question was seen: 6,663 times
last updated: Oct 19 '12, 12:53 p.m.

Related questions

Linking Work Items to Builds

0
2
David Cox (11●1●1) | asked Oct 12 '12, 11:01 p.m.

What is the difference between the "Work items reported against this build" section and the "Work items included inthis build".  I know that the "Work items included in this build" are only those work items associated in change records tied to the build.  Are "Work items reported against this build" additional work items that are resolved by this build or work items that are defects as part of this build?

Additionally can you manually add Work items included in this build links?  An example would be a defect that is resolved by another defect in the build.  I would like the testers to know all defect resolved by the build.

Accepted answer

2
permanent link
David Olsen (523●7) | answered Oct 18 '12, 12:24 p.m.
JAZZ DEVELOPER
The work items associated with a particular build are the work items associated with the change sets that were accepted into the build workspace at the start of the build.  The change sets need to be accepted into the workspace as part of the build for the work item links to show up.  If you push change sets directly to the build workspace, the change sets will show up in the "show changes" link but the work items will not be associated with the build.

I don't know a way to create "included in build" links manually after the build has run.  The only way to create those links is to have change sets accepted into the build workspace at the beginning of the build.

The "Work items reported against this build" are created manually after the build completes.  Near the top right of the Overview tab of the build result in the Eclipse client are "Create a new work item" and "Associate an existing work item" links.  Using those links will create the "reported against" link between the work item and the build result.  The purpose of these links is to identify work items that describe problems that were found in this build.
Geoffrey Clemm selected this answer as the correct answer
Comments
David Cox commented Oct 18 '12, 5:16 p.m.

David,  Thanks for the comments.  I think I'm almost there.  I tried to use the stream as opposed to a workspace for the build, but that looks like you can't accept change sets to a stream.  Therefore no changes were shown and now work items were associated to the build.

I'm not sure what you mean by push change sets directly to the build workspace.  I'm not really sure how changes sets are managed by RTC.  I thought a change set is created when you deliver code updates to the stream.  I'm not sure how RTC manages those changes sets for specific workspaces.

Since I was having so many issues with RTC automatically creating the links to Work Items from the Contribution Summary section of the build, I used the workItemPublisher to push them to the build during the ant build.  I created a text file that I manually update with the workitems before I kick off the build.  The ant build then takes those items and associates it to the build.
<taskdef name="workItemPublisher" classname="com.ibm.team.build.ant.task.WorkItemPublisherTask" />

David Cox commented Oct 18 '12, 5:18 p.m.

One other item I forgot to add to my previous post:
Some of the issues might be that when we have a build break the change sets are committed to the work stream, but can't be seen on the build.  My guess is that the build failure stops the build process and it never gets to the process to associate work items.  The second time I do the build the changes don't appear, even if it is a clean build.

One other answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Oct 13 '12, 12:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Oct 18 '12, 9:48 p.m.
Your theory is correct.   Work items included in this build are work items whose change sets are included in the configuration being built.  Work items reported against this build are ones that you explicitly associate with the build (commonly, work items that created after the build was completed, that refer to information generated by this build, such as errors reported in the build results).

Comments
David Cox commented Oct 13 '12, 2:51 p.m.

Thanks for your answer. 

 

One additonal comment.  I have a build that has a change set associated with it, but the work items are not showing on the build "Work Items" section.  Do the work items have to be a certian type or status? Is there any other reason why they wouldn't display on the build?

Geoffrey Clemm commented Oct 13 '12, 6:21 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

When you say "a build that has a change set associated with it", what in the GUI (or elsewhere) is showing you that association?

David Cox commented Oct 14 '12, 10:51 a.m.

On the build window there is a Show changes link.  When I click on that it shows the changes in the build, but nothing is displayed on the Work Items link.  How do I add additional work items to an existing build?  Why isn't there any work items associated with the current build?

Geoffrey Clemm commented Oct 15 '12, 1:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The "show changes" link is just a "compare" of the snapshot of this build with the snapshot of the previous successful build.   By "the Work Items link", I assume you mean the one in the Contribution Summary section.  If so, that would normally list all of the work items associated with any of the change sets in the "show changes" link.  So the only time I'd expect that to be empty when there were changes reported by "show changes" would be if none of the changes were associated with a work item.  Could this have been the case in your example?

David Cox commented Oct 15 '12, 9:31 a.m.

I created a new build and checked in an update to a file and associated a defect.  After the build the change showed from the "show changes" link, but there wasn't any link in the Contribution Summary section for "Work Items". 

Is there a way to search for change sets and see what build they are assocaited?

Any other thoughts on why these work items are not displaying?  Do the work items need to be in a specific state?

Can multiple work items be associated with a single change set?

Lauren Hayward Schaefer commented Oct 18 '12, 11:21 a.m. | edited Oct 18 '12, 9:49 p.m.
JAZZ DEVELOPER

I ran into the same issue David described today where I had work items associated with changesets, and they were listed in the Show Changes option but not in the Work Items section.  I fixed the issue by delivering my changesets to a repository workspace that was different from the build repository workspace.  Not sure if it matters, but the workspaces also had different owners.

Geoffrey Clemm commented Oct 18 '12, 9:49 p.m. | edited Oct 19 '12, 12:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The two related fields in the Contribution Summary, "Changes" and "Work Items", are computed in different ways (and therefore can produce different results).   The "Changes" field is based on comparing the snapshot for this build with the snapshot from the previous most recent completed, non-deleted build that has a snapshot.  The "Work Items" field is based on the change sets accepted into the build workspace by this particular build.  These fields can differ because there are a variety of ways for change sets to have been accepted into the build workspace since that previous build.
And yes, multiple work items can be associated with a single change set.

showing 5 of 7 show 2 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.