2012/2/9 Webmaster(Matt Ward)
<webmaster@xxxxxxxxxxx>
Hi Folks,
I've been in touch with the Hudson dev team and they've asked us to disable the Gerrit plugin in an attempt to track down the 'bogus' scheduling events we're seeing(they also suspect those events might be causing some of the slowdown). As such I'm going to disable the Gerrit plugin at 4pm EST to see if that improves things. If it does the Hudson team has offered to go digging in the plugin code to try and find the issue.
We tried to use the gerrit-trigger plugin installed on Hudson but so far we weren't
able to configure it correctly since the versions of the involved plugins were
incompatible, see [1].
It seems at the moment the gerrit trigger plugin isn't installed anymore: when trying
to configure the "Choosing Strategy" of the git plugin to become "Gerrit Trigger" I
can't find this setting in the "Choosing Strategy" combo any longer (previously I could
select it but not save this configuration since that failed with a ClassNotFoundException
due to incompatible plugin versions as mentioned in [1]).
Hence we were not yet able to use it since we moved the JGit/EGit repositories to
the foundation's Gerrit server and moved the review verification build jobs triggered
by the gerrit-trigger plugin from sandbox hudson to the main hudson server.
All our gerrit verification build jobs [2] which want to make use of the gerrit-trigger
plugin are disabled at the moment since they would erroneously vote -1 due to
these configuration problems.
I would recommend to use the Jenkins gerrit-trigger [3] plugin, the gerrit-trigger
plugin listed in the Hudson plugins list [4] is outdated and not maintained
anymore and the other gerrit plugin [5] according to our experience causes a quite
high load on the Hudson server since it's polling the gerrit server whereas
the gerrit-trigger plugin is relying on eventing over ssh which is much more
efficient.
