Issue 368: Notification plugin support
Status:  Released
Owner: ----
Closed:  Mar 2012
Reported by rtylerc...@gmail.com, Dec 23, 2009
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)
Dec 24, 2009
#1 sop@google.com
(No comment was entered for this change.)
Status: Accepted
Dec 27, 2009
Project Member #2 Shane...@gmail.com
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.
Jan 14, 2010
#3 sop@google.com
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.
Feb 25, 2010
#4 sop@google.com
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.
Status: Fixed
Labels: FixedIn-2.1.2
Feb 25, 2010
Project Member #5 Shane...@gmail.com
Interestingly, thats exactly the reason we wanted the hook support (aswell as
integration with our bug tracker)
Feb 25, 2010
#6 sop@google.com
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?
Feb 25, 2010
Project Member #7 Shane...@gmail.com
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.
Feb 25, 2010
#8 mike.lifeguard@gmail.com
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.
Feb 25, 2010
#9 sop@google.com
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.
Feb 26, 2010
Project Member #10 Shane...@gmail.com
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 
Feb 26, 2010
#11 mike.lifeguard@gmail.com
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.
Mar 27, 2012
#12 sop@google.com
(No comment was entered for this change.)
Status: Released