Work item customization: Command line event trigger

Hi Ben,

Unfortunately, I don't know of any way to do this other than writing an operation participant (aka follow-up action) in Java. Seems like a reasonable feature request though. I don't see a corresponding work item, so you might want to create one.

Stranded in Raleigh, figured I'd do some Friday night hacking on this. #winning

Got a basic command line participant going, but it's raising more questions:
- client-side or server-side? (I went with server-side)
- should it only run on a given state transition, or given end state, or always? Perhaps this should be optional.
- what inputs go into building the command line? Need access to work item id and other attributes? Workflow action? End state?
- does output need to get redirected to a file, or just ignored, or perhaps stored in a work item attribute? (would be weird to modify the work item in a follow-up action, but I've heard about strange lands and people having done this)
- what should be done if the exit code is non-zero? Should it fail the save?

For the configuration in the process spec, I think it would make sense to follow (some subset of) the way the Ant exec task works, using attributes/elements like executable=..., <arg value=...>, output=..., failifexecutionfails=..., etc.

Here's an example illustrating some of these ideas (not implemented yet):

<followup-actions>

    <followup-action 

		id="com.ibm.team.workitem.service.commandparticipant.CommandLineParticipant"

		name="Run Command Line"

		description="Echo info about the work item to a file">

    	<command command="echo" output="/tmp/workitemsave.txt" failifexecutionfails="true">

    		<arg value="Work item [${id}: ${summary}] with workflow action ${workflowAction}"/>

    	</command>

	</followup-action>

</followup-actions>

Stranded in Raleigh, figured I'd do some Friday night hacking on this. Got a basic command line participant going, but it's raising more questions:
- client-side or server-side? (I went with server-side)
- should it only run on a given state transition, or given end state, or always? Perhaps this should be optional.
- what inputs go into building the command line? Need access to work item id and other attributes? Workflow action? End state?
- does output need to get redirected to a file, or just ignored, or perhaps stored in a work item attribute? (would be weird to modify the work item in a follow-up action, but I've heard about strange lands and people having done this)

Woohoo! Thanks for taking a look into this! I saw the Event Handler for "Work Item State Changed Event" and thought maybe that is the best way of handling it?

This would be server side.
It should only run on a given state transition (technically, I think that's an "action"?)
Ideally, the ability to pass a work item ID and a work item field (I'd want to know the Release associated with the Deployment ticket)
The command line should be associated with the action -- that way I can associate different commands with different actions
Hmm, didn't consider the output. If there is a way of capturing it and shoving it somewhere convenient in the work item, that'd be great (good for debugging!).

Seriously, you don't have to do this all yourself -- but if you can show me how to get started I'd love to investigate it further. I really appreciate the help! I think this Deployment ticket idea would impress a customer of mine. They are attempting to write their own MySQL/PHP application with ClearCase which essentially does the same thing, but it's very difficult to maintain. The other option is to integrate RAM to RTC but that is too costly, challenging, and overkill for their needs.

Hi Ben, sure, if you haven't already, please create an enhancement request (better if it comes from you), and I'll attach the code I have so far.

Excellent!
Here is the work item: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=178551