This plugin uses Gearman to support multiple Jenkins masters. 


{jenkins-plugin-info:pluginId=gearman-jenkins|jiraComponent=gearman|sourceDir=gearman-plugin}
{jenkins-plugin-info:gearman-plugin|sourceDir=gearman-plugin}
{hudson-plugin-info:pluginId=gearmanlplugin}

Summary

Jenkins core does not support multiple masters.  You can setup multiple Jenkins masters but there is no coordination between them.

One problem with scheduling builds on Jenkins master (“MasterA”) server is that MasterA only knows about its connected slaves.  If all slaves on MasterA are busy then MasterA will just put the next scheduled build on its queue.  Now MasterA needs to wait for an available slave to run the build.  This will be very in-efficient if your builds take a long time to run.  So.. what if there is another Jenkins master (“MasterB”) that has free slaves to service the next scheduled build?  Your probably saying “Then slaves on MasterB should run the build” then I would say "good thought!".  However MasterB will never service the builds on MasterA's queue.  The client that schedules the builds must know about MasterB and then schedule builds on MasterB. This is what we mean by lack of coordination between masters. This  gearman-plugin attempts to fill the gap.

This plugin integrates Gearman with Jenkins and will make it so that any Jenkins slave on any Jenkins master can service a job in the queue. It will essentially replace the Jenkins build queue with the Gearman job queue.  The job will stay in the Gearman queue until there is a Jenkins node (master or slave) that can run that job.

Getting Started

This assumes some familiarity with Jenkins and Gearman

Install

Configuration

 

The Gearman plugin configuration should appear in the Jenkins global configuration page.  Click on the help bubbles if you need help with the configuration.  Clicking on the Launch Workers checkbox will start the gearman workers for the Jenkins server.  You should test the connection to your Gearman Server before launching the workers.

Workflow

Starting the Gearman workers:

  1. On a 'Launch Worker', a Gearman worker thread is spawned for each executor on master and slave nodes.  We'll call these "executor worker threads". Each executor worker thread is associated 1:1 with a Jenkins executor.
  2. Now we register jobs for each Gearman executor depending on the projects, labels and nodes that have been setup on the Jenkins. View the image to see how the Jenkins projects get mapped to Gearman functions.
  3. We spawn one more thread to be a Gearman worker to handle job management.  We'll call it the "management worker thread" and it will register a "stop:$hostname" Gearman function.  We use this worker to abort jenkins build jobs.  Build jobs are either on the Gearman queue or it's currently running being run by Jekins. 

Running a Jenkins build:

  1. Any Gearman client can connect to the Gearman server and send a request to build a Jenkins project.  The client just needs to provide the Gearman hostname, port, function, and UUID to start a jenkins build.  Look in github for the Gearman StartJob client example.  
  2. The Gearman workers which were spawn by the Gearman Plugin will service any client request that come through to start and cancel a Jenkins build.

Stopping a Jenkins build:

  1. Any Gearman client can connect to the Gearman server and send a request to cancel a build.  The client will need to provide the Gearman host, port and the UUID that was sent in to start the job.  Look in github for the G earman StopJob client example.

Versions

TODO

Plugin In Action