Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Hudson down?

On Fri, Jul 10, 2015 at 1:19 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:

Sent from my iPhat 6

On 10 Jul 2015, at 21:00, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote:

On Fri, Jul 10, 2015 at 12:35 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:

On 10 Jul 2015, at 20:01, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote:

On Fri, Jul 10, 2015 at 11:58 AM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:

On 10 Jul 2015, at 19:08, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote:

On Thu, Jul 9, 2015 at 11:57 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
What if the gerrit page had a "retrigger" that could send a repeat of the event to the ssh stream that included the change?

Which event? There are potentially dozens of events represented on a given change screen; are you proposing buttons next to each patch set/reviewer/inline comment/message?

However there's typically only one or two that are picked up to trigger builds:

The default one is "patchset created" so I'd suggest this is the right one to resend down the stream to re-trigger downstream builds. 

People are always asking us "when are you going to support stream-events on", and stuff like this is why my answer is usually "are you sure you want that? 'cause it kinda sucks."

OTOH this thread was kicked off because of a user of stream-events and has no bearing on whether it would be useful for

I'm just saying that stream-events is tricky and error-prone for _anybody_ and that's why I generally steer people in the direction of polling ;)

A real reliable many-to-many pubsub service with redelivery, etc. would be nifty, but stream-events is not that.

That's true - however given it's what we do have and what is used in this case and where I've seen similar in the past where people didn't have access to the build to do the retrigger (but could do a rebase which does send a patchset created message) it would be an optimisation to not do unnecessary git work just to send an event. 

It's "what is used in this case" but Hudson is not the only consumer of the event stream. Better than adding a "resend events" button that's biased towards the events this one consumer cares about, there could be a Hudson-specific plugin that adds a "Retrigger" action button and tells Hudson to inspect this change to see if it missed anything, according to exactly the observations it's interested. That limits the Hudson-specific stuff to a Hudson-specific plugin, and doesn't require any changes to Gerrit core.

As noted previously not everyone will have access to the build server nor is the assumption valid that it will always be Jenkins (or Hudson).

If this is something the admins of the Gerrit/build servers care about, they can add a plugin to Gerrit to allow untrusted users the ability to retrigger the build server on the change. It doesn't require giving users full access. Nor does it make any assumptions about the build server; each different build server can have its own "retrigger" plugin.
For example I have recently pushed reviews which failed due to the back end repository failing; but I couldn't retrigger doing a rebase (because there wasn't anything new to rebase on top of) and since I don't have admin access for the project's build server as a contributor (nor should I). 




That way you wouldn't have to rely on where the server is located and you could also retrigger failed jobs where there was a transient problem in building which was unrelated to your change. Would be better than having to amend the commit message or doing a rebase, which are the two ways you can manually do this at the moment. 


Sent from my iPhat 6

On 9 Jul 2015, at 22:45, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:

On Thu, Jul 9, 2015 at 6:56 PM, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote:
I have a series I pushed yesterday that hasn't gotten any attention from Hudson:

Any ideas why?

sometimes the ssh connection used by the gerrit-trigger plugin stops working.
Hudson admins can restart it by clicking a button under "Manage Hudson > Gerrit Trigger".

Newer versions of the gerrit-trigger plugin available for Jenkins have a
watchdog thread which auto-restarts the connection in case there are no stream events
for a configurable time period.

The latest gerrit-trigger version available for Jenkins is 2.14.0
the latest one available for Hudson is 2.5.3-h-2
on the JGit Hudson 2.5.3-h-1 is installed.

I filed
to request a modern gerrit-trigger version for Hudson

Alternatively we could raise more voices for Jenkins on

You can manually (re-)trigger a build for voting jobs here
enter a Gerrit query to find your change, select the patchset you want to build and click
"Trigger Selected".

jgit-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top