Closed GoogleCodeExporter closed 9 years ago
Original comment by sop@google.com
on 24 Dec 2009 at 9:06
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
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
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
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
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
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
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
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
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
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
Original comment by sop@google.com
on 28 Mar 2012 at 2:55
Original issue reported on code.google.com by
rtylerc...@gmail.com
on 24 Dec 2009 at 7:22