0.0.1 • Published 8 years ago

jenkins-js-widgets v0.0.1

Weekly downloads
-
License
MIT
Repository
-
Last release
8 years ago

Simple event bus for Jenkins.

Table of Contents:

TODOs

  • Basic pub-sub implementation.
  • Handle connection failure and reconnect in EventBusSession, PubSubEventPublisher and PubSubEventConsumer.
  • Add support for P2P/Queue messaging? Not sure this is needed. Would prefer to wait until we have a concrete use case.
  • Security? This might not be the right place for that though. Want this lib to remain ignorant of Jenkins core internals. Maybe we can apply security at the point in Jenkins core where this lib hooks in.
  • Basic usage example
  • Javadocs
  • Performance testing. Flood of events/messages.
  • Look into web-client consumer registration (see ActiveMQ's MessageListenerServlet, AjaxWebClient etc). Need to make sure we are using it correctly and not registering oodles of consumers etc.

Jenkins Events

Jenkins "Events" are very simple objects i.e. simple name-value pairs. Java consumers receive these events as java.util.Properties instances, while JavaScript consumers (in a browser) receive them as simple JSON objects.

The choice of this very simple structure was very intentional. We want to avoid:

  1. Bloated events.
  2. Object serialization issues.

These events are not intended to always contain all information that the consumer might possibly need. However, events should contain enough information to allow the consumer execute queries to get whatever data it needs.

The following is a sample JSON representation of a job:runStateChange event:

{
    from: "hudson.model.FreeStyleBuild",
    jobName: "Free1",
    queueId: "79",
    runId: "79",
    runNumber: "79",
    runResult: "SUCCESS",
    runStatus: "complete",
    type: "runStateChange",
    url: "job/Free1/79/"
}

Publishing an Event (server-side i.e. Java)

Publishing events requires you to "register" a "publisher" and then use that publish to "publish" events. That's easy, right?

Registering a Publisher

You can use an @Initializer to register the publisher e.g.

@Initializer(after=JOB_LOADED)
public static void init(Jenkins jenkins) {
    EventBus.getInstance().newPubSubEventPublisher("job", "Job events.");
}

Using a Publisher

The newPubSubEventPublisher function returns a PubSubEventPublisher instance, so you can use that if you have a reference to it. Otherwise, you can call getPubSubEventPublisher to get a reference.

// Create the event ...
Properties event = new Properties();
event.setProperty("XXXName", "XXXValue"); // etc etc

// Publish the event ...
PubSubEventPublisher publisher = EventBus.getInstance().getPubSubEventPublisher("job");
publisher.publish(event);

Client-side Event Consuming (JavaScript in-browser)

Consuming the event in the browser is easy enough when using modular/CommonJS style JavaScript (see jenkins-js-builder).

Consuming all events of a specific type (no filtering):

var eventBus = require('jenkins-js-eventbus');

eventBus.onPubSubEvent('job', 
    function(event) {
        // Do whatever with the event object ...
    });

Consuming a subset of events (filtering):

var eventBus = require('jenkins-js-eventbus');

eventBus.onPubSubEvent('job', 
    function(event) {
        //
        // Do whatever with the event object ...
        //
    }, {                        // Event filter:
        type: 'runStateChange', // - Only 'job:runStateChange' events
        jobName: 'Free1'        // - Only events for the 'Free1' job
    });

As an example, see buildHistoryListener.js. This example was part of removing the polling from the Build History widget and replacing it with push notifications to refresh the Build History.

Server-side Event Consuming (Java)

Consuming all events of a specific type (no filtering):

EventBus.getInstance().onPubSubEvent("job", new EventConsumer() {
        @Override
        public void onEvent(Properties event) {
            // Do whatever with the event object ...
        }
    });

Consuming a subset of events (filtering):

// Create an event filter...
Properties filter = new Properties();
filter.setProperty("type", "runStateChange"); // Only 'job:runStateChange' events
filter.setProperty("jobName", "Free1");       // Only events for the 'Free1' job

EventBus.getInstance().onPubSubEvent("job", new EventConsumer() {
        @Override
        public void onEvent(Properties event) {
            //
            // Do whatever with the event object ...
            //
        }
    },
    filter);

Example

I modified the "unbundling plugins" branch of Jenkins core to use this event bus. It's on a branch in my GitHub account: unbundling-plugins-with-event-bus.

You'll need to checkout and build this repo first, before building unbundling-plugins-with-event-bus.

On unbundling-plugins-with-event-bus, I changed how the Build History widget works, removing the polling and then making Build History refresh work based on events pushed from Jenkins i.e. events from the "Jenkins Event Bus".

Of course this also relies on changes to Jenkins core, getting it to publish events to the Jenkins Event Bus. I added a "job" event channel for job related events and then on that channel published some runStateChange events relating to builds being queued, run, complete etc.

The client side code (that listens for pushed events) is in buildHistoryListener.js. This of course relies on modular/CommonJS style JavaScript (i.e. jenkins-js-builder etc).