This plugin is deprecated. While a version 0.1 of this plugin was released, the code in subversion has been significantly reworked.. the content below on this page describes this work, but it was not completed or released.


This plugin integrates Drools with Hudson.

It lets you define your own build, test and release workflows in a graphical designer, and execute them inside Hudson. The graphical representation allows non-developers to reason about and help design processes. It also gives a much better view of the state of a process at runtime. At a glance anyone can get an idea of wat is happening with a build.

Workflows can create tasks for human users too, e.g. manual testing or signing off on releases. This is also a way to input data during the workflow.

Getting Started

This assumes some familiarity with Hudson, Eclipse and Maven.

First, install the following

 Next, we'll create a Maven/Eclipse project to develop the workflows in.

And then our first workflow...

To deploy it:

Then try it:


The Drools plugin defines some custom work items you can use in your workflows.


This is a custom work item for Hudson that starts a build and waits for completion.

Node properties:
- Project: name of project to build
- Complete when failed: complete the work item (advancing the workflow) if the build failed
- Complete when unstable: complete the work item (advancing the workflow) if the build is unstable
When the work item is not completed after the build, the user will have the choice (in the UI) to either accept the result or retry the build.
* All work item parameters of type string, boolean or RunWrapper are passed as parameters to the Hudson build.
* When build and work item are completed, the build will be available to the workflow as result parameter 'Build', wrapped in a RunWrapper.


This work item represents a script, witten in Groovy that runs inside the Hudsn JVM and has access to all Hudson internals.

Scripts have access to the following parameters:

In the script properties, only a 'Name' is specied. The actual scripts can be configured in the global Drools Management page, or on the project page (TODO).

If the script returns a Map, that is passed as a result to the workflow. Any other object will be wrapped in a Map with key 'result'.

When scripts fail (throw an exception), the workflow does not advance, and the user can manually restart them.If you don't want this, then don't throw an exception.

Human Task

A human task is a way to get user input during the workflow. Using a Groovy DSL you can define some parameters the user should enter.

The DSL code goes into the 'Content' property of the work item.


task(title:"Question?", private:false) {
    id_of_parameter_1 (
        type: "string",
        description: "What is your reply ?",
        defaultValue: "default reply"
    id_of_parameter_2 type:"boolean", description: "bla", defaultValue: true
    id_of_parameter_3 type:"choice", description: "choice parameter", choices: [ "foo", "bar" ]



On every build completion in Hudson, an event is created, called 'BuildComplete:projectName', which you can subscribe to in a workflow. However you should realize that this event may be triggered multiple times, and every event will be received by every running process instance. Consider starting this build from the workflow itself.

Additional information