Defects to "ready to verify" state when included i

My team's been using RTC for a while now, and liking it, but some of
our testers have one feature from CMVC that they miss. What they
would like is for defect work items to move into a "ready to
verify" state automatically when their changesets are included
in a successful build (ie there is something there for the tester to
verify).

I'd like to add this facility. Not being a naturally RESTful person,
I've downloaded the plain Java work item API, but without an existing
mental model of the system it's quite an intimidating wall of code. I
hope that someone here can give me some pointers of where to start.

My assumed approach is to write an Ant task that will be added to our
build script. It will have to find out which work items were included
in the build, either from information passed to the build script, if
available, or by calling back to RTC. Then, once the build has been
successful, it will need to call RTC again to move the work items
into "ready to verify" state.

I realise that "work items included in the build" isn't
trivial; I guess I mean that all changesets currently associated with
the work item are in this build; either new to it or having been
delivered some time ago.

Pointers to how to achieve my approach above are welcome; even more
welcome is advice on a better way to do it.

In general, functionality similar to what you are planning is
implemented using a Participant. I am not very familiar with the Build
infrastructure, but I assume that some kind of post build participant
can be implemented.

In the implementation you could query for all work items that have an
'included in build' link that points to the build that just finished and
change their state.

My team's been using RTC for a while now, and liking it, but some of
our testers have one feature from CMVC that they miss. What they
would like is for defect work items to move into a "ready to
verify" state automatically when their changesets are included
in a successful build (ie there is something there for the tester to
verify).

I'd like to add this facility. Not being a naturally RESTful person,
I've downloaded the plain Java work item API, but without an existing
mental model of the system it's quite an intimidating wall of code. I
hope that someone here can give me some pointers of where to start.

My assumed approach is to write an Ant task that will be added to our
build script. It will have to find out which work items were included
in the build, either from information passed to the build script, if
available, or by calling back to RTC. Then, once the build has been
successful, it will need to call RTC again to move the work items
into "ready to verify" state.

I realise that "work items included in the build" isn't
trivial; I guess I mean that all changesets currently associated with
the work item are in this build; either new to it or having been
delivered some time ago.

Pointers to how to achieve my approach above are welcome; even more
welcome is advice on a better way to do it.

In general, functionality similar to what you are planning is
implemented using a Participant. I am not very familiar with the Build
infrastructure, but I assume that some kind of post build participant
can be implemented.

In the implementation you could query for all work items that have an
'included in build' link that points to the build that just finished and
change their state.

Yes, this sounds like exactly what I want to do - the problem is that
I don't know how to do it. I can't find any good overview of how to
use the Java API I've downloaded, so I don't know where to start. Any
chance you could give at least a brief example of querying for work
items having a link?

I believe that the only Participant contribution points currently are at
request/cancel/abandon build time, not at build completion time. So I
believe you need to do these kinds of post-build operations in your
build step (using the SCM command-line), rather than using Participants.

I've submitted work item 104659, to request process enabling the "build
done" operation.

There is a Wiki page that gives an introduction to querying work items:
https://jazz.net/wiki/bin/view/Main/QueryDevGuide

An AST predicate that selects all links that refer to a build with a
specific name could look like this (untested example):

AuditableLinkQueryModel.ROOT.targetRef().referencedItem()._target(BuildResultQueryModel.ROOT).label()._eq(name);

gmclemmwrote:
I believe that the only Participant contribution points currently are
at
request/cancel/abandon build time, not at build completion time. So
I
believe you need to do these kinds of post-build operations in your

build step (using the SCM command-line), rather than using
Participants.
I've submitted work item 104659, to request process enabling the
"build
done" operation.


Thanks - I had assumed that this would be some standalone Java run as
a build step, so the lack of Participants is not a problem for me. If
the API is anything like the work item one, any savings I might gain
by reuse would be more than outweighed by the time taken figuring out
how to use it :-)

I don't see where the SCM command line comes in - I don't need to do
anything with source code. Just identify which build I'm running as
part of (which must be possible, since our other steps use build
names for directories and so on), run the work item query to see
which items link to this build, then update them as required.

Cheers,

Pete

You'll need at some point to invoke SCM operations to help find the list
of work items in the build, because I believe there is no work item API
for finding work items that are in the build

gmclemmwrote:
You'll need at some point to invoke SCM operations to help find the
list
of work items in the build, because I believe there is no work item
API
for finding work items that are in the build

I thought the query that Patrick posted was supposed to find all work
items included in a particular build?

Pete