How do you find defects that's been included in the builds?

The list of (new) work items in the build is computed by comparing the
snapshot created for the current build with the snapshot created for the
preceding successful build (from that build definition). That snapshot
comparison actually produces a list of change sets ... to get the work
items, you ask for the work items associated with those change sets.

The Change Explorer view will let you compare two arbitrary snapshots,
and the "show change sets" display will list the first work item
associated with each change set, so this would get you close. I've
submitted work item 107566 to request a "show work items" option for the
Change Explorer view, so that:
- a given work item shows up only once in the list (even when multiple
change sets are linked to the same work item)
- all associated work items appear in the list (even when a change set
is linked to more than one work item).

Cheers,
Geoff

egaona wrote:

Not sure if this has been asked before, but we're trying to do a query
of all the defect fixes that have been included in the daily builds
for a given period of time. I know in that in the build logs, you
can drill down and find out what defects changes have been included
in a particular build. Is there a query, custom or canned that I
can run that will show me all the defects that has been included in a
build? Thanks.

The list of (new) work items in the build is computed by comparing the
snapshot created for the current build with the snapshot created for the
preceding successful build (from that build definition). That snapshot
comparison actually produces a list of change sets ... to get the work
items, you ask for the work items associated with those change sets.

The Change Explorer view will let you compare two arbitrary snapshots,
and the "show change sets" display will list the first work item
associated with each change set, so this would get you close. I've
submitted work item 107566 to request a "show work items" option for the
Change Explorer view, so that:
- a given work item shows up only once in the list (even when multiple
change sets are linked to the same work item)
- all associated work items appear in the list (even when a change set
is linked to more than one work item).

Cheers,
Geoff

Geoff, thanks for the tip on the Change explorer. As for the WI 107566, definitely looking forward to seeing that feature.

Take it easy.
Enrique

The list of (new) work items in the build is computed by comparing the
snapshot created for the current build with the snapshot created for the
preceding successful build (from that build definition). That snapshot
comparison actually produces a list of change sets ... to get the work
items, you ask for the work items associated with those change sets.

The Change Explorer view will let you compare two arbitrary snapshots,
and the "show change sets" display will list the first work item
associated with each change set, so this would get you close. I've
submitted work item 107566 to request a "show work items" option for the
Change Explorer view, so that:
- a given work item shows up only once in the list (even when multiple
change sets are linked to the same work item)
- all associated work items appear in the list (even when a change set
is linked to more than one work item).

Cheers,
Geoff

Geoff, thanks for the tip on the Change explorer. As for the WI 107566, definitely looking forward to seeing that feature.

Take it easy.
Enrique

What if the build is done for the first time from a newly created Build Definition? How does the work item gets associated with the build then?

Thanks,
Binoy

On 7/14/2010 5:51 PM, binoy3012 wrote:

What if the build is done for the first time from a newly created
Build Definition? How does the work item gets associated with the
build then?

Thanks,
Binoy

You will see all the new WIs associated with all the new Change Sets
included in this first build (that means ALL). There is no difference in
behavior between the first and next build executions....

Regards,

Chemi.

There is a difference between the build result's Work Items link and its Changes link.

The Changes link is based off of snapshot comparison with the previous (completed, non-personal) build, so it is not available for the first build.

The Work Items link is based off of "included in build" links between the build result and work items, created when the change sets associated with the work items are accepted into the build workspace. If the build workspace is empty at the start of the first build, and all contents from the stream get accepted (the usual case), then yes, as Chemi says, it will include all work items for all change sets in the stream.