I don't claim to fully understand Vert.x, but it does look interesting. It sounds like a way to develop distributed event-driven apps, so this lets you create apps that interact with Jenkins?
Would you be interested in hosting this plugin in the same Jenkins org with other plugins?
I wonder if you had a chance to look at the JSON/XML serialization mechanism in Jenkins called the remote API (see http://ci.jenkins-ci.og/api for example) You might be able to take advantages of this in what you do.
On 09/19/2012 03:38 AM, Brian Lalor wrote:
I've developed a plugin[1] for Jenkins[2] that embeds the Vert.x[3] event-based framework, allowing other applications to listen and respond to Job and Build lifecycle events, as well as to influence the scheduling of queued items. For example, messages are published on the EventBus when: * Jenkins is started or shut down * a job is created, modified, copied, renamed and deleted * a build is started, completed, finalized and deleted Handlers are provided to: * schedule a build * retrieve a list of all jobs * retrieve a list of queued jobs Finally, a mechanism has provided to allow an EventBus handler to influence whether a build can be scheduled, via Jenkins' QueueTaskDispatcher extension point: a message is sent to a registered handler, and its reply is the response. The architecture is such that a clustered Vertx instance is created via the plugin, and listeners and handlers are provided by another, stand-alone Vert.x instance. This way the complexity of managing Vert.x "mods" is removed from the plugin and made the integrator's responsibility. The events and messages are documented in the README. Additionally, there's a sample app.js Verticle that can be used as a guideline for how to handle the supported messages. The current implementation blocks a job from being scheduled for a short time before allowing it to proceed. This first cut is very rough, and much to my deep, abiding shame, there are NO TESTS. I continue to struggle with Jenkins' framework for managing plugins, so much of this was written in an exploratory fashion… There are several items that should be made configurable (such as which network interfaces the embedded Vert.x instance should listen on); there is conceivably some tweakage that will need to be done before deploying the plugin. I have some ideas how I will use this plugin for my own work. I want to be able to provide a more dynamic dashboard of failing builds, implement reporting on how many builds have been failing over time, and build a more robust dependency mechanism for deployment and integration-testing jobs to make sure that the tests have a likelihood of running because the target server is actually alive. :-) I'm interested in your feedback! The first public version is available via the GitHub downloads page[4]. [1]: https://github.com/blalor/jenkins-vertx-plugin [2]: http://jenkins-ci.org [3]: http://vertx.io [4]: https://github.com/downloads/blalor/jenkins-vertx-plugin/vertx.hpi -- Brian Lalor [email protected]
-- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Nectar, our professional version of Jenkins
