Linking Work Items to Builds
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
Comments
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" />
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
Comments
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?
When you say "a build that has a change set associated with it", what in the GUI (or elsewhere) is showing you that association?
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?
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?
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?
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.
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.