Notification plugin support

[GoogleCodeExporter]

While Gerrit plugin support in general I think is a good idea, narrowing 
the scope to "notification" plugins makes it a bit more malleable of a 
task. 

For example, a Yammer, Twitter. Campfire or Jabber plugin for a particular 
project. When a developer pushes changes to be reviewed they could be 
invoked to post a message to Yammer like "@tyler has submitted 'Enable new 
config option' (12dcf3) for review: http://gerrit/26"

I would imagine a notifier plugin would need to implement a few hooks:
  * Review published
  * Comment published
  * Patch updated
  * Patch merged

On the front-end side of things, adding plugin .jar's from the Admin 
interface would be sufficient so long as they could provide a hook for 
ocnfiguration options per-project.

(fwiw, I'm thinking along the lines of plugins for Hudson: 
http://wiki.hudson-ci.org/display/HUDSON/Plugins#Plugins-Buildnotifiers)

Original issue reported on code.google.com by rtylerc...@gmail.com on 24 Dec 2009 at 7:22

[GoogleCodeExporter]

Original comment by sop@google.com on 24 Dec 2009 at 9:06

• Changed state: Accepted

[GoogleCodeExporter]

I'd personally prefer to see https://review.source.android.com/9414 finished 
(with
all the different update types as mentioned in the 7th comment) and merged 
before
this is added.

Original comment by Shane...@gmail.com on 28 Dec 2009 at 5:11

[GoogleCodeExporter]

Although we don't have notifier plugin support, change
Ic2f041a71c744d0938d79b1106c9119d6318731a adds hooks
that can be run from $site_path/hooks for the events you
listed in the original description.

Original comment by sop@google.com on 14 Jan 2010 at 6:40

[GoogleCodeExporter]

Also, change Iba3ff56c23ab91cf3b855d5dde6c40d9735b643f adds
support to monitor events over SSH using a JSON structure.

Kenny developed this so he could write an IRC bot that sent
merged messages onto an IRC channel.  So I think the command
solves the original request.

What I like about doing an external notification process is
users can run notifiers even on servers they don't administer.
So anyone who has a project on review.source.android.com can
still run their own Yammer, Twitter or Jabber notification tool
by hosting on their own server, and just connecting over SSH to
get the events.

Right now there is a potential for the notifier to lose events
when the connection goes down.  In the future as we migrate to
a Git database storage, stream clients will be able to bookmark
the event they last saw, and pick up streaming from that point
when they reconnect.

Original comment by sop@google.com on 25 Feb 2010 at 5:35

• Changed state: Fixed
• Added labels: FixedIn-2.1.2

[GoogleCodeExporter]

Interestingly, thats exactly the reason we wanted the hook support (aswell as
integration with our bug tracker)

Original comment by Shane...@gmail.com on 25 Feb 2010 at 5:48

[GoogleCodeExporter]

ShaneMcC, I'd actually love to just delete the hook support you
contributed and only support this stream-events command.  I don't
like the idea of making the Gerrit daemon fork out and execute
external processes, its horribly messy under Java and can be costly
if your OS doesn't have a proper spawn() command and your heap size
is huge (like 8 GiB).

So... can I kill the hook support in favor of this?

Original comment by sop@google.com on 25 Feb 2010 at 5:51

[GoogleCodeExporter]

I rather the hook stuff, it (imo) allows nicer integration with things like 
mantis 
bug tracker (which has a pre-existing support for post-commit vcs hooks) and 
our IRC
bot listens on a socket for what to say and we can just netcat to it when its 
time to
say something.

The bot might not be online all the time and it seems less than ideal to have a
separate process running just sitting connected to gerrit reading the stream 
and then
spawning its own processes todo things like the mantis hook (which is more 
important
to us than the IRC Bot), or talk to our IRC Bot.

Original comment by Shane...@gmail.com on 25 Feb 2010 at 8:06

[GoogleCodeExporter]

I agree with ShaneMcC... hooks are the standard way to implement this for good
reason. Listening on ssh seems like an incredibly fragile setup, and less 
flexible.
Keeping an ssh connection open forever sounds like a bad way to accomplish what
should be executed on the server.

Original comment by mike.lifeguard@gmail.com on 26 Feb 2010 at 12:25

[GoogleCodeExporter]

I fail to see how listening over SSH is less flexible.

I'm about to push the build to review.source.android.com.  Once
its there, *anyone* can run their own event monitors against that
server.  They just have to host the process on their own system.

The rsac server already has hook support... and nobody except for
me can use it.  Not sure how that is more flexible.

I guess an alternative way to ensure delivery of events is... the
tried and true method of email.  If we took the event monitor JSON
and shoved it into an email message and sent it out, then clients
just have to scan a POP or IMAP mailbox.  Failures are automatically
recovered from as the mail system retries delivery.  Latency just
might be higher than the SSH connection method.

Original comment by sop@google.com on 26 Feb 2010 at 1:01

[GoogleCodeExporter]

Anyone being able to run event monitors against the server is great for other 
people,
but I need to perform certain actions on the server when certain things happen, 
so
hooks that only run on the server are fine for this purpose

 - When a new patchset is commited or merged, I need to run a script that lets my bug
tracker know so that it can add a note about it and set the issue status to 
"pending
fix" or "resolved"

 - When a new patchset is commited I add this to a queue of patches that need to be
test-compiled by our rudimentary CI script (which is run from crontab and reads 
what
to do from the queue)

The former at least doesn't lend itself well to the new system as it was 
originally
designed to be run from an svn hook, then we modified it to run from a git 
hook, and
now a gerrit hook.

We've tried parsing from emails before when we used google code for svn 
hosting, it
was quite a horrible way of doing it, and one of the reasons we switched to a
self-hosted solution, and it seems equally horrible to have to create a whole 
new
application to connect via ssh and parse the json feed and then just run the 
hooks as
before.

In my case, I'm not hugely bothered what other people want to do with the 
events from
my server, I care more for the stuff I want/need to do with it which lends 
itself
nicer to being run from hooks 

Original comment by Shane...@gmail.com on 26 Feb 2010 at 4:41

[GoogleCodeExporter]

Parsing emails is not tried and true, it is almost always a bad idea :)

"They just have to host the process on their own system." Well, perhaps your 
users
have systems where running such a process makes sense. Many do not. For my 
purposes,
it only makes sense to have server-side hooks set up by the server admin. You 
see it
as a limitation, I see it differently. Perhaps both have their niches.

Original comment by mike.lifeguard@gmail.com on 26 Feb 2010 at 11:30

[GoogleCodeExporter]

Original comment by sop@google.com on 28 Mar 2012 at 2:55

• Changed state: Released