| Issue 368: | Notification plugin support | |
| 6 people starred this issue and may be notified of changes. | Back to list |
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
Status:
Accepted
Dec 27, 2009
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
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
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
Interestingly, thats exactly the reason we wanted the hook support (aswell as integration with our bug tracker)
Feb 25, 2010
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
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
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
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
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
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
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |