Commit Graph

103 Commits

Author SHA1 Message Date
Antoine Musso 0c47b4292d Retire the project on OpenDev
It has been migrated to the Jenkins community:
https://github.com/jenkinsci/gearman-plugin/

Depends-On: Ib6010d7ce85a934501c50a53e9ac78dcf74bc403
Change-Id: I0c84db2ad3fbb4d9f0eff793a0159c6ed3a8e25c
2021-05-27 17:23:43 +02:00
Jan Hruban 46d74f029f Fix permission problem when finding builds
Plugin runs as user "anonymous". Escalate priviledges so it can find
projects/builds also in the case that "anonymous" user does not have
read permissions for them.

Change-Id: Iccf19460bb02a450d4a82fdabaf9dbc37a3ffe97
2016-03-21 09:44:28 +01:00
Jenkins b879f56ef1 Merge "Update to Jenkins LTS 1.625.3 and fix function registration" 2016-03-18 16:23:36 +00:00
Jenkins c5637cef49 Merge "Register the diff of functions" 2016-03-08 21:49:21 +00:00
Clark Boylan 73359c0456 Register the diff of functions
Instead of registering all functions for every node each time the
functions change register the delta of the functions each time. This
should cut down on the amount of CAN_DO updates we were doing in the
past.

Note that we handle the loss of all functions with RESET_ABILITIES
rather than sending a CANT_DO for each function that is no longer
available. Also, starting a new connection will always begin with
RESET_ABILITIES to clear any potentially stale state from the gearman
server.

Change-Id: I2b16117fce30ddb3e11b338043204cf726c7f1d4
2016-03-08 10:32:26 -08:00
Khai Do a5164d65a4 Update to Jenkins LTS 1.625.3 and fix function registration
Using a newer Jenkins LTS (ver 1.625.3) did not work with the
gearman-plugin. Gearman function registeration wasn't working
correct because Computer.currentComputer()[1] and getInstance()[2]
methods seemed to always return null on initialization of the
plugin. The Jenkins.getActiveInstance method (introduced in
Jenkins-1.589)[3] works more reliably.

[1] http://javadoc.jenkins-ci.org/hudson/model/Node.html#getNodeName()
[2] http://javadoc.jenkins-ci.org/jenkins/model/Jenkins.html#getActiveInstance()
[3] e6c2e16f7a

Change-Id: I1534beda9c39a9d15da4d7b96f17e7b75699a631
2016-01-24 06:14:52 -08:00
Timothy Chavez 2f10c6a06f Send node labels back on build completion
Zuul will not necessarily know which node type the job it dispatches
to Jenkins will run on, so we send that information back to Zuul on
build completion so it can use it to submit metrics in that context.

Change-Id: Ibca938fcf8a65facd7e39dab4eb994dfc637722a
2015-08-25 16:37:07 -05:00
Khai Do 08e9c429de Fix deadlock from a WORK_FAIL event
A lock is kept on a gearman worker when a WORK_FAIL event happens.
This causes the worker therad to stall on the next attempt that
the AvailabilityMonitor attempt to get a lock on the worker.
This causes the jenkins nodes to stop working (not run builds
anymore). Unlock the worker on a WORK_FAIL event to avoid this
deadlock state.

This fixes issue https://issues.jenkins-ci.org/browse/JENKINS-28891

Change-Id: I015ce9732fd535676a832680f39e220b09df95cf
2015-07-01 10:17:20 +00:00
Jenkins f2024bd53e Merge "Use TextParameterValue instead of String" 2015-06-18 02:17:11 +00:00
Jenkins 0314ab1ea2 Merge "Fix race between adding job and registering" 2015-05-06 20:09:00 +00:00
Clark Boylan 65a08e0e95 Fix race between adding job and registering
Gearman plugin had a race between adding jobs to the functionList and
registering jobs. When registering jobs the functionMap is cleared, when
adding a job the plugin checks if the job is in the function Map before
running it. If we happen to trigger registration of jobs when we get a
response from gearman with a job assignment then the functionMap can be
empty making us send a work fail instead of running the job.

To make things worse this jenkins worker would not send a subsequent
GET JOB and would live lock never doing any useful work.

Correct this by making the processing for gearman events synchronous in
the work loop. This ensures that we never try to clear the function map
and check against it at the same time via different threads. To make
this happen the handleSessionEvent() method puts all events on a thread
safe queue for synchronous processing. This has allowed us to simplify
the work() loop and basically do the following:

  while running:
    init()
    register()
    process one event
    run function if processed
    drive IO

This is much easier to reason about as we essentially only have
bookkeeping and the code for one thing at a time.

Change-Id: Id537710f6c8276a528ad78afd72c5a7c8e8a16ac
2015-05-05 14:39:21 -07:00
James E. Blair 7abfdbd2d0 Stop sending status updates
Don't send status updates every 10 seconds.  Only send them at the
start of a job (to fill in information like worker and expected
duration, etc).  We don't actually do anything with subsequent
updates, and if Zuul wants to know how long a job has been running
it's perfectly capable of working that out on its own.

Change-Id: I4df5f82b3375239df35e3bc4b03e1263026f0a68
2015-05-05 10:39:53 -07:00
James E. Blair 6de3cdd29b Protect against partially initialized executer workers
The registerJobs method of an executorworker can be invoked by an
external caller before the worker is completely initialized by
its run method.  We protected against that by checking one instance
variable, but there's still a race condition involving another.
Add a check for that variable as well.

Change-Id: I8e2cfffb54aa8a4cf8b1e61e9a9184b091054462
2015-01-08 08:40:26 -08:00
Khai Do fa5f0834ff Fix job result not being sent back to gearman client
This fixes a bug that causes the result object to be left off of the
returned data packet after a job finishes executing.  This only occurs
when the job request sets the node to temporary offline (i.e.
"OFFLINE_NODE_WHEN_COMPLETE":"true").  The problem is that the
ComputerListener.onTemporaryOffline event was stopping the
gearman worker which causes a disconnect to the gearman client thus
not being able to send back the results for the job.  The worker should
not stop on a temporary offline, only on disconnect and delete of a node.
The fix is to only re-register the gearman functions instead of stopping
the workers on a temporary online/offline of a node.

Change-Id: Icf672acf059d6cb0e16a6685d637824c678ea5be
2014-10-21 15:14:20 -07:00
Khai Do 6307ba2225 update to work with Jenkins LTS ver 1.565.3
This change updates the gearman-plugin to build against Jenkins LTS
ver 1.565.3.  This is required to support later versions of Jenkins
because there have been changes to Jenkins events in core.

This change adds the ItemListener to re-register gearman
functions on changes to jenkins projects.  Using the ItemListener is
better because it provides more details on the item that's been
changed and the events are more grandular.  There was also a change
to ComputerListener events (onTemporaryOffline and onTemporaryOnline)
that needed to be handled seperately in this change.  The SaveableListener
is still needed due to a bug in ItemListener.

The most notable change to function registration is that the gearman
plugin will no longer register functions containing a node's self label.

For example:
Assume you have the following setup:
  a node: named 'trusty-slave1' and labeled 'trusty'
  a job: named 'my-job' that targets the 'trusty' label

The gearman plugin used to register the following functions:
'build:my-job', 'build:my-job:trusty' and
'build:my-job:trusty-slave1'

With this update the gearman plugin will only register
'build:my-job' and 'build:my-job:trusty'.  It will no
longer register functions containing the implicit
node name (trusty-slave1).

If your gearman client has been using explicit labels
to execute builds then this change will not affect
your workflow.

Closes-Bug: #1353891
Change-Id: I9e57ec9f24bf303989a4df1fc4f1a0c4b6d001bc
2014-10-15 14:21:08 -07:00
James E. Blair b37c6a2789 Use TextParameterValue instead of String
If a value with a newline is received, Jenkins does not display the
value correctly in the parameters page.  Based on a quick reading
of similar issues elsewhere, it may also not save the value correctly
for later use by plugins such as the 'rebuild' plugin.  Switching
from string to text parameter types solves this.  However, it does
cause _all_ parameters to be treated as text, which wastes a bit of
real-estate on the parameters listing screen with tall textboxes.
We could scan the string for '\n' and choose appropriately as an
alternative.

Change-Id: I84ef198fd6ef852fc0a403e126f13b8cbb58a7b1
2014-07-02 16:54:15 -07:00
James E. Blair 6961c9d441 Fix project-node registration
Previously, a node would register the ability to run a job under
all labels associated with the project if the node matched at
least one of them.  What we really want to do is, if the node
matches any project label, register the generalized job and then
also register it for each label in the _intersection_ of project
labels and node labels.

Change-Id: Ie41af7b1a2f26a4ca2aac6c7263817d5021cca9b
2014-06-20 12:16:46 -07:00
Khai Do 67f6b2342b fix function registration.
Fixed registration for slaves that have the 'usage' configuration set to
"Leave this machine for tied jobs only"

Change-Id: Ieeb16ae9070915b3461379af9e50ae6fd69f22d7
Closes-Bug: #1253429
2013-11-24 17:40:21 +00:00
James E. Blair ad75b7e0b0 Set a node offline even if there is an exception
In particular, an InterruptedException is likely in the portions
of safeExecuteFunction that wait for the Jenkins job to complete.
In those cases, we still want to return an exception, but we also
want to make sure that once we have scheduled a build on a node,
when that build is finished (even if it is due to some catastrophe
such as a failure to communicate with the node), we still take
the node offline.

We have seen the occasional scheduled job stuck in Jenkins because
of a situation where a node fails, and the gearman plugin schedules
another build on the node because the offline method has not run.
Meanwhile, nodepool deletes the node (because Jenkins said the
job finished) and the scheduled build gets stuck.  This should
eliminate that.

Change-Id: I69b1e4b21430b7427ed47c3cb43bd94e04213321
2013-09-25 11:04:31 -07:00
James E. Blair af21876dfe Always return WORK_COMPLETE when a build finishes regardless of
the result.

This is a change to the Zuul-Gearman protocol, however, Zuul is
already compatible with this mode of operation.

The new idea is that WORK_COMPLETE should be returned for every
completed job, regardless of the result.  The result of the build
should be determined by the client by inspecting the data returned
with the WORK_COMPLETE packet.

WORK_FAIL should now instead be used to indicate that the job failed
to run for some reason (perhaps the scheduler was, after all, unable
to schedule a build that it had accepted from the gearman server).

WORK_EXCEPTION continues to indicate something similar to WORK_FAIL,
but with exception information attached.

(At the moment, gearman-plugin should now only return WORK_COMPLETE
or WORK_EXCEPTION; the option to use WORK_FAIL as described is a
future enhancement.)

Change-Id: I32187065dac7e83573636021faf964df8dfd63be
2013-09-16 14:11:11 -05:00
James E. Blair 8e62012466 Don't wait for the worker thread to join
If a node is deleted, it can call the AbstractWorkerThread.stop
method while holding the monitor lock on the Jenkins object.  This
will interrupt the GearmanWorkerImpl thread, and then wait for it
to join.  However, if at that moment, the GWI is trying to set
the node offline (due to OFFLINE_NODE_WHEN_COMPLETE being set),
then the system will deadlock while that thread tries to grab
the Jenkins object monitor in order to save the new node
configuration.

Instead, just don't wait for the thread to join, which will
eventually release the monitor lock and allow the GWI thread
to complete.

Change-Id: Ic8dbdf73551feb684ac4f3e46d2ee3e5aef976db
2013-08-16 12:55:37 -07:00
Khai Do 9f388435d2 remove restriction on slave to run single job at a time
The gearman plugin was restricting slaves to runnning
only one job at a time even though the slave may have the
ability to run multiple jobs in parallel (by having
multiple executors).  This commit fixes the restriction.

Change-Id: I62b4ff9d12474a5885c549f0b532366cb60fcbca
2013-08-16 08:04:10 -07:00
Jenkins 2d6558ead7 Merge "moved python examples to jenkins wiki" 2013-08-15 01:14:23 +00:00
James E. Blair 2cb540bf51 Use more fine-grained synchronization in GearmanProxy
This undoes some of the previous change.  In particular, calling
something that could affect a NodeAvailabilityMonitor's lock
(eg in canTake or the init methods in createExecutorWorkersOnNode)
can deadlock on trying to obtain the Queue lock while holding the
GearmanProxy lock.

Instead, lock on just the handle lists where necessary, and try
to do serious work outside of that lock.

Change-Id: I4c1ed6c7a4f5586c1034651a649bbbd420eacdd7
2013-08-14 14:50:14 -07:00
James E. Blair c97253eff5 Rework starting/stopping executors
There was at least one error, likely a race condition, with the
previous code which could cause more than one ExecutorWorkerThread for
a node to be spawned.  In particular, I think the bogus comparison in
ComputerListenerImpl may have a large part in that (it checked to see
if a _Computer_ object was in a list of _Thread_ objects).

To improve reliability around adding and removing nodes, all related
functionality is moved to the GearmanProxy class.  Any methods (most
of them) that have to do with starting or stopping worker threads are
synchronized on the GearmanProxy monitor (the important parts of most
threads were already synchronized on the worker list before, so this
should not be much of a performance change).

The methods that start management and executor threads now do their
own checking to verify that such threads do not already exist, making
it so that calling them is more idempotent.  Existing checks external
to the class have been removed (these were likely somewhat racy).

To avoid keeping redundant data structures, the node availability list
is removed, and instead if we need to find an availability object, we
walk the list of worker threads and compare to their nodes.  Because
we do this so much, the list of worker and management threads are
changed to use those explicit classes instead of
AbstractWorkerThreads.

The accessor methods for the internal lists of worker threads is
removed to ensure that they are only managed through GearmanProxy.
This changed some unit tests and required the removal of one complete
test (which was not doing much more than verifying the addition
operator).

Also, when stopping ExecutorWorkerThreads, stop all of the ones
associated with a node.

When a computer goes offline, Computer.getNode() returns null, so we
can't know which workers should be deleted.  Instead of using Nodes as
keys for our workers, use Computers instead and change everything to
use Computer (most functions needed Computer rather than Node anyway),
and in the few remaining places where a Node is needed, convert the
other direction.

Change-Id: Ia5084579317f972400069cc3e84db4e0b6560a80
2013-08-13 11:31:50 -07:00
Khai Do 0ebbf00604 moved python examples to jenkins wiki
Removed python examples from this java project.  The examples were using the
python 'gearman' library.  New examples using jeblair's 'gear' library have
been created on the jenkins gearman plugin wiki at
https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin

changed to python 'gear' because it's better than the gearman library.

Change-Id: I54f2d2a52f6b2eaf2f15433aee62525d5b3621b6
2013-08-11 07:20:24 -07:00
James E. Blair e45ffe249d Add OFFLINE_NODE_WHEN_COMPLETE option
If a build job is requested with the "OFFLINE_NODE_WHEN_COMPLETE"
parameter set to a true value, then mark the node as temporarily
offline when the build is complete (regardless of the outcome).

This facilitates single-use slaves (or slaves that need cleanup
after their jobs).  "Temporarily offline" was chosen as the
most lightweight method of preventing new builds to facilitate
either performing an external cleanup action (which would then
online the existing node), or external deletion of the node.

To accomplish this, the NodeAvailabilityMonitor unlock call is
moved from the StartJobWorker gearman function out into the gearman
worker so that the lock is held during the entire run of the job
and further past the point where the StartJobWorker will set
the node offline.

Also, supply the name of the gearman worker (which includes the
node name) with the build data to the client.  This way the client
will know which worker performed the job, and whose node may need
to be manipulated if the offline flag is set.

Change-Id: I5cda75eb44b26ec58e5f03d0aa980af09ee023f6
2013-08-06 11:09:14 -07:00
Jenkins 84a20df823 Merge "ignore non-deterministic build failure and log it." 2013-07-18 01:04:46 +00:00
zaro0508 13b4b52968 ignore non-deterministic build failure and log it.
maven builds intermittently fail due to something in the code.
essentially its the same issue as in bug 1201035.

This patch makes it so the build ignores the error and just logs
it so that we can have a record of the error.  Hopefully we
can use logstash to query for a pattern to determine the
root cause of this problem.

The error on this build:
  java.lang.NullPointerException
      at hudson.plugins.gearman.ExecutorWorkerThread.registerJobs(ExecutorWorkerThread.java:150)
      at hudson.plugins.gearman.SaveableListenerImpl.onChange(SaveableListenerImpl.java:68)
      at hudson.model.listeners.SaveableListener.fireOnChange(SaveableListener.java:78)
      at hudson.model.AbstractItem.save(AbstractItem.java:474)
      at hudson.model.Job.save(Job.java:154)
      at hudson.model.AbstractProject.save(AbstractProject.java:273)
      at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.parsePoms(MavenModuleSetBuild.java:915)
      at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:622)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
      at hudson.model.Run.execute(Run.java:1575)
      at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:241)

Change-Id: I16fb0261312fe0aef55d2f2b6c83652333aed05a
2013-07-16 10:01:00 -07:00
James E. Blair a9adc4b7d9 Make logging more consistent
Change-Id: Ifedb1ddbd7663900438fd89f2eabb3c1f4c2a5aa
2013-07-11 12:39:24 -07:00
James E. Blair 9bacb54664 Avoid holding locks on gewtHandles.
Some of the operations we were doing on worker threads while
iterating over the list of worker threads were fairly deep and
themselves required locks.  Instead, try to hold the lock on
worker thread lists as short as possible.  Snapshot them and
iterate over the snapshot when doing complicated tasks.

Change-Id: I4c257e83b2a2f985bf571f4f64e2db44d2d17e3d
2013-06-15 10:15:43 -07:00
James E. Blair 2ba8b61b3a More deadlock fixes.
It's possible that some InterruptedExceptions were being hidden by
the GrabJobEventHandler, which must catch those and not throw them.
So wherever we call driveSessionIO, check to make sure that we are
still supposed to be running afterwords.

Make sure all other places where InterruptedException is caught
do something reasonable with it.

Remove printStackTrace calls and replace with logging calls.

Change-Id: I0790eece8582c1ee2cd28e8866bfd4a9d5d700cd
2013-06-14 21:22:27 -07:00
James E. Blair 352664ee95 Send final packet immediately.
Rather than waiting for it to be sent on the next pass through the
loop.

Change-Id: If77bf1e0be6946d6a0b5db33cec5d1caf98cd058
2013-06-14 17:28:08 -07:00
James E. Blair 474afb007b Use AbstractProject instead of Project in function factory.
Fixes an illegal argument exception.

Change-Id: I9a1fde359e043b7cdf2fb1e635ac65a6196dc0c0
2013-06-14 16:17:11 -07:00
James E. Blair eb27ce4c23 Don't catch InterruptedException in the node monitor.
It is probably because someone is trying to shut down this thread.
Instead, allow it to propogate up where existing code around
sendGrabJob handles it correctly.

Change-Id: Ia51bdd7e81262e10386b9253dcb2cfb4294f3097
2013-06-14 15:24:12 -07:00
James E. Blair 4556818799 Report exceptions while running the job to the client.
Don't catch any exceptions while running the job; instead, report
them back to the client (via a catch-all exception handler in
StartJobWorker).

If the worker raises an exception, unlock the node monitor, in case
the worker didn't get to the point where it would be unlocked.

This change has the side effect that if the gearman server disconnects
while the job is running, the worker should return from watching the
job run (as soon as it notices, currently up to 5 seconds).  This is
helpful in that it will be available to register with gearman again,
including sending CAN_DO packets.  But the node monitor will still
prevent it from scheduling a new job while the one it started earlier
is still running.

Change-Id: Ie01ef0f9e706d81452b189099e36242ab9967950
2013-06-14 15:23:07 -07:00
James E. Blair 6041401766 Handle mutex scheduling from Gearman or Jenkins.
Every node (slave or master) gets an AvailabilityMonitor that
handles mutually exclusive access to scheduling builds on that
node.  If Jenkins wants to run a build on the node, it will only
be able to do so if we are not waiting for a response to a
GRAB_JOB packet from Gearman.  Likewise, immediately before
sending a GRAB_JOB, we lock the monitor and only unlock it if
we either get a NO_JOB response, or after the job we were just
assigned starts building.

(As an exception to the above rule, since Jenkins will apply the
same scheduling veto logic to the build that we request via Gearman,
(while we still hold the lock) we tell the monitor to expect a request
for that build from Jenkins and we permit Jenkins to build it even
if the lock is held.)

Change-Id: Iae03932aef4b503c69699b99d38a6fc2691fb02e
2013-06-13 12:42:51 -07:00
James E. Blair 76cb343b8c Don't grab jobs when shutting down.
This rearranges a bit of the previous change to move the WaitBool
functionality into an AvailabilityChecker class.

It implements the new feature of not grabbing jobs while not in the
quiet mode for shutdown by using a busy wait.  There doesn't seem to
be an event framework for that, and well, it doesn't happen very
often, so a slow busy wait probably isn't terrible.

This only applies to Executor workers, not Management workers
(so jobs can still be stopped and descriptions set).

Removed the default-name constructor of AbstractWorkerThread because
it is not used anywhere now (removed its test as well).

Change-Id: I6d5e1cd3cb47c8876ceb909d205cb66445388992
2013-06-12 07:59:46 -07:00
James E. Blair 858fb155fe Don't grab a job when executors are busy.
Jobs can be triggered by non-gearman sources, sadly.  This makes the gearman
plugin aware of when executors are busy and it will refrain from grabbing a
job from gearman in those circumstances.

It's far from perfect, but should at least handle the most likely cases where
a job is already running an an executor.

Change-Id: If993c6d6bc63ed89b385d2e5bb41762ef84a429f
2013-06-11 16:04:09 -07:00
zaro0508 18a3fa68cc always run management worker
This commit is a fix to bug 1185952.

While the jenkins host is running its master node may
be in a disabled state (master has 0 executors) however the
host should still be able to run a management worker and
communicate with a Gearman Server.  This commit makes
sure that the manaegement worker runs regardless
the master node's state.

This commit also makes sure that we are setting the management
worker's name to something.

Change-Id: I871019fadde47787cfe20bec666e24d242728f30
2013-06-11 15:18:04 -07:00
James E. Blair b4e3ed8e3a Make worker threads more resilient.
If an unhandled exception happens during the work method, shut
down the worker and start again.

Also, name worker threads for easier debugging.

Change-Id: Icc8e4c060bca4ab624bffc2e1bef18655d50d6b2
2013-06-07 15:30:52 -07:00
James E. Blair 2f579179bb Fix build description permission error.
Impersonate the system user while setting build description because
the gearman plugin runs outside of a user context.

Change-Id: Ib8a0eacd44c067a22e6c5afc7a0984a247792f1e
2013-06-07 10:53:43 -07:00
James E. Blair 61e47a1e8b Handle not connecting at start.
We previously assumed that we would connect to gearman immediately and be able
to send a SET_CLIENT_ID packet; that would raise an exception and stop any
further gearman processing.  Instead, don't assume we can send that packet,
and also, do send it immediately after reconnecting.

Also, lower the retry delay from 3 second to 2.  I don't think we'll mind
Jenkins being in a tighter loop because it probably won't be doing anything else.

Change-Id: Id585726e23076ad22e2935173995db2bdadf9974
2013-06-06 15:40:05 -07:00
James E. Blair 7a8d940c4b Update zuul-gearman protocol.
* Use name+number as the build identifier for all meta-jobs.
  (Zuul has name + number as build metadata, so avoid adding new/duplicate
  features).
* Refer to the name of the manager worker as 'manager' instead of 'master'
  to avoid jenkins specifics.
* Just call the url "url" instead of "full_url".
* Change SetDescriptionWorker to use name+number as the build id.
  Also, expect 'html_description' instead of 'description'.
* Don't catch as many exceptions, instead, let them propogate so that they
  get turned into WORK_EXCEPTION packets with information (instead of
  WORK_FAIL packets which have no info).
* Change StopJobWorker to use the same name+number interface as
  setDescriptionWorker (for consistency, expandability, plus it makes
  the code simpler).

Change-Id: I8e078540c252bf9c1f14b79f8182517cbaa13555
2013-06-06 15:40:01 -07:00
zaro0508 78abc3d903 Added a Stop() method to handle stopping executor worker threads.
fix for bug 1181569

Refactored how stop was handled.  Removing thread and stopping thread
in the same syncronized loop was causing concurrent modification error.
Needed to seperate the actions for it to work.

Change-Id: I99b676f377842826f9e6a847cfeff76be91c8299
2013-05-31 11:53:56 -07:00
James E. Blair 0b017fe95d Rework when GRAB_JOB is sent.
* Send GRAB_JOB after NO_OP.
* Send GRAB_JOB after initial setup to start the event-state system.
* Don't send GRAB_JOB after changing the functions.  The gearman server will
  maintain the existing state of the connection if functions change, so if
  we are sleeping, we will still get appropriate NOOP messages even after
  changing functions.
* Don't send GRAB_JOB when the task queue is empty.  The event-state system
  should send it when necessary.
* Send GRAB_JOB after job completion (to restart the event-state system).

Fixes 1183454.

Also fixes cases where we would end up grabbing multiple jobs in one cycle.

Change-Id: I36a890711ecdfef62a6554bac820acf0ca8b5f5b
2013-05-24 16:55:38 -07:00
zaro0508 09241a692a remove comment and use generic AbstractWorkerThread object.
Change-Id: Ibe3631635e24f9f54e10179f88d90e4e190b43a8
2013-05-21 10:04:12 -07:00
zaro0508 42c95ac958 add gearman worker to set build descriptions
This commit adds another management worker for setting a build's descriptions.
The worker will lookup the build by it's build_id (jobName:jobId)
and if it can find it then will set the description and return with COMPLETED.
If it cannot find the build or cannot set the description for any reason
it will return FAILED.

This commit also adds teh build_id to the data returned by the StartJobWorker.

Usage:

  client = gear.Client()
  client.addServer('localhost')
  client.waitForServer()
  job_name = 'set_description:JenkinsHostName'
  data = {'build_id':"pep8:2013-05-15_17-32-07",'description':"<h1>My Test Build</h1>"}
  job = gear.Job(job_name, simplejson.dumps(data))
  client.submitJob(job)

Change-Id: I4990772d591d27bbb3b4f20abfb4d988077b4995
2013-05-18 11:26:15 -07:00
zaro0508 0de925f6d8 fix for bug 1162887
Users no longer need to disable the plugin to connect to
a different gearman server.

Along with this commit I changed the 'launchWorker' plugin config name to
'enablePlugin' because enabling plugin is distinct from running gearman workers.

Change-Id: Ia81d78da3dbdc83fd46dd7f5d40ccb9aca3af97f
2013-05-01 10:20:45 -07:00
zaro0508 07026b7b71 fix intermittent test failure
I believe this test failed because the jenkins slave node that gets
created in the test does not come online fast enough.  The
test now polls to make sure the slave is online before continuing.

Change-Id: I2a86d0b550daf70e5d2041994d78ff5e4649a62b
2013-04-30 14:51:12 -07:00