It's all about the answers!

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

×42,831
×10,865

question asked: Jan 28 '10, 8:31 p.m.
question was seen: 10,683 times
last updated: Jan 28 '10, 8:31 p.m.

Related questions

Defects to "ready to verify" state when included i

0
Peter Verdon (61●2●3●2) | asked Jan 28 '10, 8:31 p.m.
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.

Cheers,

Pete

13 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Patrick Streule (4.9k●2●1) | answered Feb 03 '10, 4:23 a.m.
JAZZ DEVELOPER
Patrick's query was for all work items that "refer" to a particular
build, where "refer" means work items that were explicitly linked by an
end user to that build (for example, you can submit a new defect against
a build, and that new defect will "refer" to that build).

The work items I was talking about were those that contained change-sets
that contributed changes to the build ... there are not explicit links
from the build object to those work items.

Patrick: Correct?

There are two types of links between builds and work items: The explicit
ones as 'Found in Build' and the automatically created ones 'Included in
Build'.

I was thinking of the 'Included in Build' ones. They are automatically
calculated from the change sets that went into the build. So you could
let the build do the calculation and then simply query based on those links.

The query itself was more an example of how to query links, but would
need some additional conditions:

- Limit the links to the 'Included in Build' ones
- Limit the work items on the other side of the link to the 'Resolved' ones

--
Regards,
Patrick
Jazz Work Item Team
0
permanent link
Peter Verdon (61●2●3●2) | answered Feb 03 '10, 10:42 a.m.
Thanks for confirming the links I need are there, and the additional conditions I need. I will probably be looking only for work items in a custom "developer believes it's ready to be verified once it's gone through a build" state, which will then be stepped into "awaiting verification" by the tool.

So far I have the following four lines: 


IPredicate workItemsLinkedToBuild = AuditableLinkQueryModel.ROOT.targetRef().referencedItem()._target(BuildResultQueryModel.ROOT).label()._eq("exampleBuild_123");

        

IDataQuery query = IDataQuery.FACTORY.newInstance(AuditableLinkQueryModel.ROOT);



query.select(AuditableLinkQueryModel.ROOT.itemId());

query.filter(workItemsLinkedToBuild);

(no, it didn't take me a whole week to get this far; it's just something I spend the occasional five minutes on)

I guess I need some surrounding infrastructure to actually use this query, some of which I might be able to crib from the snippets in the JazzPlainJavaClient zip.

It's really difficult trying to use this stuff without any javadoc, or (as far as I could find) any kind of overview documentation to explain the conceptual shape of the API as opposed to individual tactical details. I know that explaining concepts can be difficult when you're seeing a project from the inside (my own product isn't great on this score either), but for a public interface the absence of JavaDoc is frankly poor.

I did find this blog post from someone else needing documentation; it seems he was able to download the source in order to obtain the javadoc. Is this still possible - despite the masthead on this site inviting me to "download code", I can't find anywhere to do so?

Thanks,

Pete
0
permanent link
Peter Verdon (61●2●3●2) | answered Feb 03 '10, 11:18 a.m.
Just to note I've now got in touch with the blog author - who turns out quite by chance to be an IBMer in the next office! - and downloaded the SDK source in order to obtain the javadoc.

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.