CloudEvents plugin for Jenkins

Goal: Be able to listen to and emit cloudevents from Jenkins.

Status: Completed

Team

Details

Background

As the CI/CD world is moving more towards interoperability between multiple platforms, Jenkins should also be compatible with the same interoperability standards. Some of these standards with respect to communication between different CI/CD platforms are put forth by the cloudevents specification. This spec outlines the structure of cloudevents, which are produced or consumed by entities which support it, hence making those entities compatible with other CI/CD platforms which also support them allowing them to work together.

Jenkins currently does not support cloudevents, making it hard for users to use it with other platforms which support them.

Project Details

This project idea proposes to implement a Jenkins plugin which extends Jenkins to make cloudevents both discoverable and subscribable. Users should be able to set a global configuration to allow users to subscribe and discover cloudevents.

The project requires the student to start with plugin development from scratch and then work with understanding how to use the Cloudevents Java SDK to create and read events.

In the beginning, the student can work on understanding the Jenkins plugin development by writing code for creating a simple Build Step which creates a CloudEvent, and from there we can move to the GlobalPluginConfiguration on how Jenkins should listen to the cloudevents.

Implementation

Jenkins as a Source

This plugin extends from Listener classes inside the Hudson-Model package (Listeners in Jenkins), which offers listener-implementation for various events inside the Jenkins server.

The data received from the object-listeners is wrapped into CloudEvents spec using CloudEvents Java SDK as the event payload. In order for this payload to become CloudEvent-compliant, some additional metadata, in the form of headers, need to be passed along in the HTTP request. Using the GlobalConfiguration information received from the user, the event payload along with custom HTTP headers will be sent over to the given HTTP Sink.

An example of what event-payload can look like for a CloudEvent emitting from Jenkins upon a job-build-success

 {
	"result": "SUCCESS",
	"endTime": 1469453903,
	"ciUrl": "http://localhost:8080/jenkins/",
	"fullJobName": "test_job",
	"number": 252,
	"jobName": "test_job",
	"duration": 11252,
}

Here is an example of additional headers which must be passed along to make the event data CloudEvent-compliant

ce-specversion: 1.0
ce-type: job.build.finished
ce-source: <Jenkins' Server>
ce-id: <Custom UUID>

Jenkins as a Sink

This stage will involve implementing RootAction associated to a Jenkins object which would listen to CloudEvents from external systems sent via HTTP. After extracting the CloudEvent payload, a new action will be taken inside the Jenkins server depending upon the source which triggered the event and the type of the event.

Deliverables

  1. Jenkins as a Source

    • Extend GlobalPluginConfiguration within the CloudEvents Plugin to support listening and emitting Jenkins events for Jenkins objects (projects, runs, build, etc) across the Jenkins server.

    • UI Changes to allow a user to configure Jenkins as a Source and Sink for emitting and consuming CloudEvents respectively.

      • Configuration of the external URL of an HTTP Sink where CloudEvents from Jenkins will be sent.

      • Selection of events a user would like to send over to the Sink (build-started, build-building, build-finished).

    • Listen to Jenkins events across the Jenkins server, and wrap the event-data into CloudEvent-compliant spec to send via HTTP to a Sink.

  2. Jenkins as a Sink

    • Implement RootAction associated with Jenkins objects (Jobs, Projects, Queues). The URL of the Action will be receiving HTTP requests with CloudEvents payload.

    • Traverse the request received, and extract data which will decide the next action to take within Jenkins.

    • Trigger the next action inside Jenkins server. For example, build project #5 upon data change event from Debezium.

  3. Documentation and testing

    • Rigorous testing and documentation along each stage.

Chat

We use the #gsoc-2021-jenkins-cloudevents-plugin channel in the CDF Slack workspace. How to join CDF Slack.

Office hours

The CloudEvents Plugin SIG Meeting happens every Monday at 13:00 UTC.

Zoom Link: https://cloudbees.zoom.us/j/94985456924 (ID: 94985456924, passcode: 167462)

Links