It's all about the answers!

Ask a question

Auto transition of workitems included in a build


Brian Gillan (3215130) | asked Jul 29 '09, 8:54 a.m.
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



permanent link
Nick Edgar (6.5k711) | answered Jul 29 '09, 7:11 p.m.
JAZZ DEVELOPER
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?

permanent link
Brian Gillan (3215130) | answered Jul 30 '09, 8:53 a.m.
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

permanent link
Geoffrey Clemm (29.3k23035) | 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
(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

permanent link
Brian Gillan (3215130) | answered Aug 28 '09, 9:17 a.m.
Geoffrey Clemm wrote:
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.


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

permanent link
Geoffrey Clemm (29.3k23035) | 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:
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.


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

Your answer


Register or to post your answer.