You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2010/04/22 22:06:47 UTC
Feature idea: user-configurable post-commit notifications
With the increased integration of build tools and other notification systems
which desire knowledge of commit activity, it would be useful to provide an
easier mechanism of installing post-commit notification, without having to
use the hook infrastructure. Imagine a user being able to set up commit
mails, CIA notifications, and buildbot notifications *without* having to
have access to the repository. To that end, I propose the following.
Simply a versioned property, which, when encountered during the course of a
commit, causes the server to emit a notification. This property would be a
list of URLs, to which the repository would send a specially formatted POST
with the information about the commit. (The idea being that a committer to
the project could set up this property, as well as the server which receives
these notifications, all without the intervention of the repository
administrator.) As part of the bubble up, the repo would queue these URLs,
and then POST to them during the post-commit phase of the commit.
Thoughts?
(Hat tip goes to Kohsuke Kawaguchi of Hudson for the idea.)
-Hyrum
Re: Feature idea: user-configurable post-commit notifications
Posted by Branko Čibej <br...@xbc.nu>.
On 23.04.2010 11:45, Bert Huijben wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: vrijdag 23 april 2010 0:57
>> To: Hyrum K. Wright
>> Cc: Subversion Development
>> Subject: Re: Feature idea: user-configurable post-commit notifications
>>
>> Write a hook script to do exactly that, and make it part of the
>> standard release.
>>
>> In some future release, after that script and its features stabilize,
>> *then* we can consider placing into into the core code.
>>
>> I fear the security aspects of something like you talk about: anybody
>> with commit access getting the server to issue a POST request to any
>> arbitrary URL *reachable* by the server? Oh ho ho... I can't even
>> begin to describe how many alarms that would trip with security
>> conscious administrators.
>>
> +1 on all of this.
>
*Shudder*. I'm not all that rabidly security-conscious but the very idea
raises the hair on the soles of my feet. Which is quite something
considering that I don't have any there.
Interestingly enough you do not even have to write a hook script that
does that. As long as your repository has any kind of subscribable
commit notification, e.g., uses mailer.py, you can trigger secondary
client-side notifications off of that.
-- Brane
RE: Feature idea: user-configurable post-commit notifications
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: vrijdag 23 april 2010 0:57
> To: Hyrum K. Wright
> Cc: Subversion Development
> Subject: Re: Feature idea: user-configurable post-commit notifications
>
> Write a hook script to do exactly that, and make it part of the
> standard release.
>
> In some future release, after that script and its features stabilize,
> *then* we can consider placing into into the core code.
>
> I fear the security aspects of something like you talk about: anybody
> with commit access getting the server to issue a POST request to any
> arbitrary URL *reachable* by the server? Oh ho ho... I can't even
> begin to describe how many alarms that would trip with security
> conscious administrators.
+1 on all of this.
Bert
Re: Feature idea: user-configurable post-commit notifications
Posted by Greg Stein <gs...@gmail.com>.
Write a hook script to do exactly that, and make it part of the
standard release.
In some future release, after that script and its features stabilize,
*then* we can consider placing into into the core code.
I fear the security aspects of something like you talk about: anybody
with commit access getting the server to issue a POST request to any
arbitrary URL *reachable* by the server? Oh ho ho... I can't even
begin to describe how many alarms that would trip with security
conscious administrators.
Cheers,
-g
On Thu, Apr 22, 2010 at 18:06, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> With the increased integration of build tools and other notification systems
> which desire knowledge of commit activity, it would be useful to provide an
> easier mechanism of installing post-commit notification, without having to
> use the hook infrastructure. Imagine a user being able to set up commit
> mails, CIA notifications, and buildbot notifications *without* having to
> have access to the repository. To that end, I propose the following.
>
> Simply a versioned property, which, when encountered during the course of a
> commit, causes the server to emit a notification. This property would be a
> list of URLs, to which the repository would send a specially formatted POST
> with the information about the commit. (The idea being that a committer to
> the project could set up this property, as well as the server which receives
> these notifications, all without the intervention of the repository
> administrator.) As part of the bubble up, the repo would queue these URLs,
> and then POST to them during the post-commit phase of the commit.
>
> Thoughts?
>
> (Hat tip goes to Kohsuke Kawaguchi of Hudson for the idea.)
>
> -Hyrum
>
Re: Feature idea: user-configurable post-commit notifications
Posted by Neels J Hofmeyr <ne...@elego.de>.
Johan Corveleyn wrote:
> On Wed, Apr 28, 2010 at 11:58 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> [...]
>> We use that in a hook script that forbids
>> commits that replace nodes -- because some users often do that by accident,
>> fragmenting history --
>
> Probably because of this bug?
> http://subversion.tigris.org/issues/show_bug.cgi?id=3429 - "svn mv A
> B; svn mv B A" generates replace without history
>
> Our users also run into that multiple times a month. It's just so easy
> for this to happen in an agile/Java/refactor-often environment...
> You're working on something; move things around a bit; change your
> mind; move some more; ready, commit. If this issue would be fixed,
> accidental replaces would be far less common ...
>
> Anyway, OT for this thread, but this is also one of those issues that
> I really hope to be resolved by wc-ng. Maybe it should be marked
> milestone 1.7?
Hi Johan,
wc-ng is not the solution of all problems. Basically, wc-ng is spring
cleaning and maturing the structure in which we store working copy metadata.
What is true though is that a substantial number of things will get
infinitely easier to fix once we are at 1.7. And it may also be true that
someone takes the time to fix #3429 before the 1.7 release cycle kicks off.
But these events are not necessarily directly correlated. Try to spread your
high hopes evenly about a given time span... :)
The fact that you're mentioning this might already be the cue point for
someone to start fixing this. But if you need it urgently, you can always
allocate man-power directly to this issue (try fixing yourself, or pay
someone to do it, maybe other power users are willing to chip in).
<obligatory-remark>That's what Open Source is all about.</obligatory-remark>
(And, I, too, hope it will get fixed sooner rather than later. Subversion
tracks history explicitly for each node, and that issue is obviously a Bad
break with this paradigm.)
~Neels
Re: Feature idea: user-configurable post-commit notifications
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Apr 28, 2010 at 11:58 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
[...]
> We use that in a hook script that forbids
> commits that replace nodes -- because some users often do that by accident,
> fragmenting history --
Probably because of this bug?
http://subversion.tigris.org/issues/show_bug.cgi?id=3429 - "svn mv A
B; svn mv B A" generates replace without history
Our users also run into that multiple times a month. It's just so easy
for this to happen in an agile/Java/refactor-often environment...
You're working on something; move things around a bit; change your
mind; move some more; ready, commit. If this issue would be fixed,
accidental replaces would be far less common ...
Anyway, OT for this thread, but this is also one of those issues that
I really hope to be resolved by wc-ng. Maybe it should be marked
milestone 1.7?
Cheers,
--
Johan
Re: Feature idea: user-configurable post-commit notifications
Posted by Neels J Hofmeyr <ne...@elego.de>.
Bolstridge, Andrew wrote:
>> -----Original Message-----
>> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
>> Sent: Mon 26/04/2010 19:27
>> To: Bolstridge, Andrew
>> Cc: dev@subversion.apache.org
>> Subject: RE: Feature idea: user-configurable post-commit notifications
>>
>> Bolstridge, Andrew wrote on Fri, 23 Apr 2010 at 13:52 +0100:
>>> So imagine if I (as a server admin, of course) could configure a new
>>> command ("svn review" or "svn special-cmd review") that uses the
>>> same mechanism as pre-commit, and calls the server hook
>>> "special-review.pl". That's 3 data items in server and client
>>> configuration - ('review', 'pre-commit', 'special-review.pl').
>
>> Just to clarify: I assume you intend that script to be run on the server
>> (using data provided by the client)?
>
> Yes, all on the server - exactly like the existing infrastructure.
> I'm not suggesting any of this be run on the client.
Re not firing a hook event with every commit: you could parse the log
message and make it so that your mechanism is only or not triggered when a
certain word or phrase is found. For a wild example, write the hook so that
it does not trigger a publish to your web if the commit's log message
contains the string "(PRELIM)". We use that in a hook script that forbids
commits that replace nodes -- because some users often do that by accident,
fragmenting history -- so if a user really knows the deal, she can write
ALLOW REPLACES anywhere in the commit message and is not bothered by the
hook anymore.
~Neels
RE: Feature idea: user-configurable post-commit notifications
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
>-----Original Message-----
>From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
>Sent: Mon 26/04/2010 19:27
>To: Bolstridge, Andrew
>Cc: dev@subversion.apache.org
>Subject: RE: Feature idea: user-configurable post-commit notifications
>
>Bolstridge, Andrew wrote on Fri, 23 Apr 2010 at 13:52 +0100:
>> So imagine if I (as a server admin, of course) could configure a new
>> command ("svn review" or "svn special-cmd review") that uses the
>> same mechanism as pre-commit, and calls the server hook
>> "special-review.pl". That's 3 data items in server and client
>> configuration - ('review', 'pre-commit', 'special-review.pl').
> Just to clarify: I assume you intend that script to be run on the server
> (using data provided by the client)?
Yes, all on the server - exactly like the existing infrastructure.
I'm not suggesting any of this be run on the client.
RE: Feature idea: user-configurable post-commit notifications
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Bolstridge, Andrew wrote on Fri, 23 Apr 2010 at 13:52 +0100:
> So imagine if I (as a server admin, of course) could configure a new
> command ("svn review" or "svn special-cmd review") that uses the
> same mechanism as pre-commit, and calls the server hook
> "special-review.pl". That's 3 data items in server and client
> configuration - ('review', 'pre-commit', 'special-review.pl').
Just to clarify: I assume you intend that script to be run on the server
(using data provided by the client)?
RE: Feature idea: user-configurable post-commit notifications
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
On 23.04.2010 00:06, Hyrum K. Wright wrote:
> With the increased integration of build tools and other notification
> systems which desire knowledge of commit activity, it would be useful
> to provide an easier mechanism of installing post-commit notification,
> without having to use the hook infrastructure.
I have a slightly different suggestion (but it's in roughly the same area):
Special, or Custom, commands
I was thinking about ReviewBoard and how to make automatic reviews of svn diffs. I have seen people create pre-commit hooks that would run the necessary review script if a certain log comment was specified and then "fail" in the commit, which is one way to do it, and others where the review was posted *every time* code was committed. However, I thought wouldn’t it be very nice to be able to create new client commands that call server hooks directly (ie without having to bodge the required features into an existing hook).
So imagine if I (as a server admin, of course) could configure a new command ("svn review" or "svn special-cmd review") that uses the same mechanism as pre-commit, and calls the server hook "special-review.pl". That's 3 data items in server and client configuration - ('review', 'pre-commit', 'special-review.pl').
Obviously there would be some limitations to this - the data that is sent would have to be the same as the existing hooks, but if I could add a line of config to the client to do this, that would be a rather cool feature to subversion.
This would help with the features requested by this thread - eg, if you want to update your web server, you'd run a new command 'deploy to web', etc. The benefit to this is mainly that you might not want your web server updated all the time with the code you've just committed - especially if you like to checkin partially-developed code. (eg when you go away for the weekend and are worried you might lose your laptop, or your PC dies).
Anyway, that's just an idea for the roadmap :)
Re: Feature idea: user-configurable post-commit notifications
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Fri, 23 Apr 2010 at 07:17 -0400:
> And I'll go one further: also provide a (sample) CGI script to
> *accept* those POST requests, and "do something". At the ASF, our
> website is updated after a commit. The code that does that today is
> apparently a little flaky, so having an officially
Incidentally, the code that does that *works* by sending an HTTP request
(PUT, not POST) from the hook. Which isn't that far from the original
idea here...
> supported/tested/maintained solution for that kind of scenario would
> be in our best-interest, let alone helping umpteen million downstream
> users.
>
> Cheers,
> -g
>
Re: Feature idea: user-configurable post-commit notifications
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Apr 23, 2010 at 07:07, Stefan Küng <to...@gmail.com> wrote:
>...
>>> On 23.04.2010 00:06, Hyrum K. Wright wrote:
>>>>
>>>> With the increased integration of build tools and other notification
>>>> systems
>>>> which desire knowledge of commit activity, it would be useful to provide
>>>> an
>>>> easier mechanism of installing post-commit notification, without having
>>>> to
>>>> use the hook infrastructure. Imagine a user being able to set up commit
>>>> mails, CIA notifications, and buildbot notifications *without* having to
>>>> have access to the repository. To that end, I propose the following.
>>>>
>>>> Simply a versioned property, which, when encountered during the course
>>>> of
>>>> a
>>>> commit, causes the server to emit a notification. This property would
>>>> be
>>>> a
>>>> list of URLs, to which the repository would send a specially formatted
>>>> POST
>>>> with the information about the commit. (The idea being that a committer
>>>> to
>>>> the project could set up this property, as well as the server which
>>>> receives
>>>> these notifications, all without the intervention of the repository
>>>> administrator.) As part of the bubble up, the repo would queue these
>>>> URLs,
>>>> and then POST to them during the post-commit phase of the commit.
>>>>
>>>> Thoughts?
>...
> After re-reading the proposal: doesn't Google Code already have something
> like this implemented?
> http://code.google.com/p/support/wiki/PostCommitWebHooks
Yup!
Tho I can guarantee they have already isolated those outgoing requests
from their serving/internal networks and infrastructure. Would your
average IT administrator do the same? :-P
Regardless of the security stuff, I think your reference is quite
valid. It would be great for svn to provide a script to follow that
model/specification.
And I'll go one further: also provide a (sample) CGI script to
*accept* those POST requests, and "do something". At the ASF, our
website is updated after a commit. The code that does that today is
apparently a little flaky, so having an officially
supported/tested/maintained solution for that kind of scenario would
be in our best-interest, let alone helping umpteen million downstream
users.
Cheers,
-g
Re: Feature idea: user-configurable post-commit notifications
Posted by Stefan Küng <to...@gmail.com>.
On 23.04.2010 13:00, Greg Stein wrote:
> On Fri, Apr 23, 2010 at 06:53, Stefan Küng<to...@gmail.com> wrote:
>> On 23.04.2010 00:06, Hyrum K. Wright wrote:
>>>
>>> With the increased integration of build tools and other notification
>>> systems
>>> which desire knowledge of commit activity, it would be useful to provide
>>> an
>>> easier mechanism of installing post-commit notification, without having to
>>> use the hook infrastructure. Imagine a user being able to set up commit
>>> mails, CIA notifications, and buildbot notifications *without* having to
>>> have access to the repository. To that end, I propose the following.
>>>
>>> Simply a versioned property, which, when encountered during the course of
>>> a
>>> commit, causes the server to emit a notification. This property would be
>>> a
>>> list of URLs, to which the repository would send a specially formatted
>>> POST
>>> with the information about the commit. (The idea being that a committer
>>> to
>>> the project could set up this property, as well as the server which
>>> receives
>>> these notifications, all without the intervention of the repository
>>> administrator.) As part of the bubble up, the repo would queue these
>>> URLs,
>>> and then POST to them during the post-commit phase of the commit.
>>>
>>> Thoughts?
>>
>> We have something similar in TortoiseSVN: client-side hook scripts.
>> Some people use those to send out notifications after a commit, some to copy
>> files to their webserver, ...
>> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks
>>
>> But TortoiseSVN gathers all information purely on the client side. So I'm
>> not sure if this feature in svn would require a server-side change or hook
>> script to do that?
>
> If the committers use various clients, then yes: some kind of
> server-side solution would be needed.
Sorry, I misread the proposal and thought the data the server gathers
would be sent back to the client and the client would then do whatever
it wants.
After re-reading the proposal: doesn't Google Code already have
something like this implemented?
http://code.google.com/p/support/wiki/PostCommitWebHooks
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Feature idea: user-configurable post-commit notifications
Posted by Stefan Küng <to...@gmail.com>.
On 23.04.2010 13:00, Greg Stein wrote:
> On Fri, Apr 23, 2010 at 06:53, Stefan Küng<to...@gmail.com> wrote:
>> On 23.04.2010 00:06, Hyrum K. Wright wrote:
>>>
>>> With the increased integration of build tools and other notification
>>> systems
>>> which desire knowledge of commit activity, it would be useful to provide
>>> an
>>> easier mechanism of installing post-commit notification, without having to
>>> use the hook infrastructure. Imagine a user being able to set up commit
>>> mails, CIA notifications, and buildbot notifications *without* having to
>>> have access to the repository. To that end, I propose the following.
>>>
>>> Simply a versioned property, which, when encountered during the course of
>>> a
>>> commit, causes the server to emit a notification. This property would be
>>> a
>>> list of URLs, to which the repository would send a specially formatted
>>> POST
>>> with the information about the commit. (The idea being that a committer
>>> to
>>> the project could set up this property, as well as the server which
>>> receives
>>> these notifications, all without the intervention of the repository
>>> administrator.) As part of the bubble up, the repo would queue these
>>> URLs,
>>> and then POST to them during the post-commit phase of the commit.
>>>
>>> Thoughts?
>>
>> We have something similar in TortoiseSVN: client-side hook scripts.
>> Some people use those to send out notifications after a commit, some to copy
>> files to their webserver, ...
>> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks
>>
>> But TortoiseSVN gathers all information purely on the client side. So I'm
>> not sure if this feature in svn would require a server-side change or hook
>> script to do that?
>
> If the committers use various clients, then yes: some kind of
> server-side solution would be needed.
Sorry, I misread the proposal and thought the data the server gathers
would be sent back to the client and the client would then do whatever
it wants.
After re-reading the proposal: doesn't Google Code already have
something like this implemented?
http://code.google.com/p/support/wiki/PostCommitWebHooks
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Feature idea: user-configurable post-commit notifications
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Apr 23, 2010 at 06:53, Stefan Küng <to...@gmail.com> wrote:
> On 23.04.2010 00:06, Hyrum K. Wright wrote:
>>
>> With the increased integration of build tools and other notification
>> systems
>> which desire knowledge of commit activity, it would be useful to provide
>> an
>> easier mechanism of installing post-commit notification, without having to
>> use the hook infrastructure. Imagine a user being able to set up commit
>> mails, CIA notifications, and buildbot notifications *without* having to
>> have access to the repository. To that end, I propose the following.
>>
>> Simply a versioned property, which, when encountered during the course of
>> a
>> commit, causes the server to emit a notification. This property would be
>> a
>> list of URLs, to which the repository would send a specially formatted
>> POST
>> with the information about the commit. (The idea being that a committer
>> to
>> the project could set up this property, as well as the server which
>> receives
>> these notifications, all without the intervention of the repository
>> administrator.) As part of the bubble up, the repo would queue these
>> URLs,
>> and then POST to them during the post-commit phase of the commit.
>>
>> Thoughts?
>
> We have something similar in TortoiseSVN: client-side hook scripts.
> Some people use those to send out notifications after a commit, some to copy
> files to their webserver, ...
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks
>
> But TortoiseSVN gathers all information purely on the client side. So I'm
> not sure if this feature in svn would require a server-side change or hook
> script to do that?
If the committers use various clients, then yes: some kind of
server-side solution would be needed.
Cheers,
-g
Re: Feature idea: user-configurable post-commit notifications
Posted by Stefan Küng <to...@gmail.com>.
On 23.04.2010 00:06, Hyrum K. Wright wrote:
> With the increased integration of build tools and other notification systems
> which desire knowledge of commit activity, it would be useful to provide an
> easier mechanism of installing post-commit notification, without having to
> use the hook infrastructure. Imagine a user being able to set up commit
> mails, CIA notifications, and buildbot notifications *without* having to
> have access to the repository. To that end, I propose the following.
>
> Simply a versioned property, which, when encountered during the course of a
> commit, causes the server to emit a notification. This property would be a
> list of URLs, to which the repository would send a specially formatted POST
> with the information about the commit. (The idea being that a committer to
> the project could set up this property, as well as the server which receives
> these notifications, all without the intervention of the repository
> administrator.) As part of the bubble up, the repo would queue these URLs,
> and then POST to them during the post-commit phase of the commit.
>
> Thoughts?
We have something similar in TortoiseSVN: client-side hook scripts.
Some people use those to send out notifications after a commit, some to
copy files to their webserver, ...
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks
But TortoiseSVN gathers all information purely on the client side. So
I'm not sure if this feature in svn would require a server-side change
or hook script to do that?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net