Auto transition of workitems included in a build
Is there any means of automatically transitioning work items that have
been included in a build? Either with process customizationm, or if this doesn't exist, could it be done programatically? Brian |
5 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 28 '09, 4:01 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Writing a generic process to automatically transition a work item to
"complete" is problematic, because you don't know what state to transition to (the state model of of process can be arbitrarily customized), and even if you did know that state, there might be required fields that must first be given a value. But for a given process area, with a specific state model and set of required field semantics, you could logically write a custom trigger. In order to implement this, you'd need to use the work item rest interface (see https://jazz.net/wiki/bin/view/Main/WebSearch?topic=ResourceOrientedWorkItems). Also note that there is a request that this be simplified by providing a command line mechanism for updating work items (work item 83846). Cheers, Geoff Brian Gillan wrote: Geoffrey Clemm wrote: |
|
Geoffrey Clemm wrote:
There is a work item for request 1: 20663. Thanks Geoff. The 88913 covers the second part of item 2, but it seems it would still be useful to be able to customize the process to automatically transition WIs that have been included in a siuccessful build. That way, they could be picked up in a WI query, and also, a subscriber could be automatically notified when an item has been fixed, and is included in a good build. Brian |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 30 '09, 3:29 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
There is a work item for request 1: 20663.
I've submitted a work item for request 2: 88913. Note that you can today see a list of all change sets that have been incorporated since the last build (just not since the last *good* build). Similarly, you can today see a list of the first builds that contain a work item, but not the first *good* build that contains a work item. Cheers, Geoff Brian Gillan wrote: Thanks. This is mainly to benefit the QE side of things. With CMVC |
|
Thanks. This is mainly to benefit the QE side of things. With CMVC
(version control system currently used by many of our products), when a build is run, if it's successful, defects/enhancements that were incorporated into that build get transitioned to a Verify state and this the QE folks know what has been fixed and in what build the fix resides. Would be nice if similar function could be achieved in RTC. With RTC, when using the build toolkit, teamAccept accepts all changesets delivered to the parent stream since the last build was done, and then creates a snapshot. The resulting build may be successful or fail. Regardless of success or failure, the changsets (and associated work item records) are captured in that build result. So even if a build fails, the next build snapshot and build result record will only reflect changes since the last build was run, whether that build was good or bad. To net this out. The uses would like an easy way to: 1. See a list of all change sets/work items that have been incorporated since the last good build. 2. When viewing a work item, see whether it's been fixed or not, and if it has, what the successful build is that incorporated this fix. Thanks, Brian |
Brian,
There's no easy way of doing this out-of-the-box. It's possible to do this programmatically, e.g. one could write an Ant task to query for the work items associated with a build, then change their state. It's not clear that you'd want to do this using process hooks. Process preconditions and participants (follow-up actions) apply to user actions, such as requesting a build, not to the running of the build itself. And even if you hooked the request build operation, it would not apply for automatically scheduled builds. Can you describe what you're trying to do at a higher level? What's the use case? |
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.