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.

Summary

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.

Click on the MyFirstWorkflow project. You should see a the workflow graph.

Start a MyFirstWorkflow build. On the build page you should see a graph for the workflow process instance.

A Project1 build should be started.

Manual

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

Build

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.

Script

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:

session (the Drools StatefulKnowledgeSession)

hudson (Hudson.getInstance())

args (a map with the parameters passed by the workflow)

out (a PrintWriter that logs to the build log)

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.

When completed, a result parameter will be created for every question, with the same id.

If ActorId is present, only a Hudson user with the same id can complete the task

If private is true, only the actor can see the task (not tested yet)

Events

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

When a Run object (the record of a build) needs to be passed as a parameter or a result, it is always wrapped into a hudson.drools.RunWrapper object.

The renderer of workflows supports WorkItem, HumanTask, Build, Script, Split, Event, Start, End and ForEach nodes.Other nodes work are rendered as a black&white box showing only the node name. Connections are always rendered as straight lines from center to center.