Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324699

Summary:	[build][workflow] add mechanism for handling build actions
Product:	z_Archived	Reporter:	Torkild Resheim <torkildr>
Component:	Mylyn	Assignee:	Project Inbox <mylyn-triaged>
Status:	CLOSED MOVED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	greensopinion, steffen.pingel
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	357472

Description Torkild Resheim

2010-09-07 16:47:57 EDT

Being able to view build job information and to some extent control building is useful. However much more is achieved by adding an extra level of integration; having actions take place when a job changes state.

The idea is that various action types are contributed through Eclipse extension points. They contribute a user interface for action configuration and the code required for executing the action. One can for instance be able to download and unzip a built artifact when a job has completed successfully or automatically open the JUnit view with test results if any tests fail. More advanced configurations such as executing a shell script can also be possible.

Adding an action type involves the following steps:
* Declaring the action with a label, identifier and a pointer to the implementation.
* Implementing the action; supplying a method for handling the configuration GUI and another for executing the action.

One or more actions can be specified for each build job. Right clicking on a job and selecting "Build Actions..." should will a configuration dialog where actions can be added and configured. The configuration data is stored when OK is pressed and used when the action is executed.

Comment 1 Steffen Pingel

2010-09-08 15:29:28 EDT

Interesting idea. We have received requests to add support for workflow automation for tasks in the past which sounds very similar. This would be a good opportunity to gather experience by making it work for (Hudson) builds while keeping generalization in mind.

Comment 2 David Green

2010-09-16 13:12:57 EDT

How do you see this kind of feature working if Eclipse is not running?  Would it skip running these actions?  Would it be possible to run these actions on demand (ie: by user interaction with the UI)?

Comment 3 Torkild Resheim

2010-09-16 16:37:48 EDT

(In reply to comment #2)
> How do you see this kind of feature working if Eclipse is not running?  Would it
Do you mean for instance when being a part of the Tasktop application? I don't see any problems with that. As long as the various actions have all their dependencies in place they could run. If not, their contributing plug-ins would not be installed so they would not be available. If an action for some reason is configured but unavailable it should be ignored.
> skip running these actions?  Would it be possible to run these actions on demand
> (ie: by user interaction with the UI)?
Yes, we could add an extra flag to the declaration that indicates that such use is allowed and add these actions to the context menu of build jobs.

Comment 4 David Green

2010-09-16 19:32:36 EDT

(In reply to comment #3)
> (In reply to comment #2)
> > How do you see this kind of feature working if Eclipse is not running?  Would
> it
> Do you mean for instance when being a part of the Tasktop application? I don't
> see any problems with that. As long as the various actions have all their
> dependencies in place they could run. If not, their contributing plug-ins would
> not be installed so they would not be available. If an action for some reason is
> configured but unavailable it should be ignored.

What I mean is, if the actions are to be triggered upon status change, how does this functionality behave if/when the Eclipse process is terminated and restarted 12 hours later (for example).  If the status of a build changes 20 times in that period, how would Eclipse behave when it is restarted?  Would it simply ignore all of the status changes, would it trigger those actions for the most recent change, how do you see this working?

Comment 5 Torkild Resheim

2010-09-18 03:30:09 EDT

Ah. Thank you for the clarification David. In my current implementation only status changes taking place while Eclipse is running will trigger actions. My initial idea was to keep it simple. But as Steffen has indicated, this could evolve into something far more useful. So maybe it would be a good idea being able to keep track of all status changes. Even those that take place while Eclipse is not running.

The idea was that this mechanism could allow the user to download a file or play a sound when something happened. That would only be useful if the user was present when the status change took place.

Comment 6 Eclipse Webmaster

2022-11-15 11:45:08 EST

Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn