Re: [Trac] VCS hook control from Trac web admin?
On Tue, Feb 21, 2012 at 4:38 PM, Magnus Therning mag...@therning.org wrote: On Tue, Feb 21, 2012 at 09:56:25AM -0500, Olemis Lang wrote: On Tue, Feb 21, 2012 at 9:27 AM, Magnus Therning mag...@therning.org wrote: On Tue, Feb 21, 2012 at 14:41, Olemis Lang ole...@gmail.com wrote: On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning mag...@therning.org wrote: [...] Also, the configuration is probably somewhat more involved if hook functions are allowed to come as separate Trac plugins. Configuration is basically , install enable plugin , activate hook in hook admin panel , set parameters . You are ready to go ;) I see the *implementation* of the configuration to be more complicated. I think there are good reasons to be able to enable a function for a subset of the VCS repos only. I also think there are good reasons to be able to configure the functions with different parameters for each VCS repo. I agree . All this is correct even if not available at the moment as the plugin is design for 0.11 . So basically it's a TODO ;) The options I see then is that each function comes with its own admin page, or that each function can hook into an admin page. Both of these are more involved. I was thinking of doing something somehow different . Focus on an scenario similar to Bitbucket . You have many repositories each one having hooks admin page where you select «functions» to trigger and, for each active «function» , specify parameters . I don't see why we cannot implement something as simple as that ... especially considering the fact that it's possible to do it the way we want to (i.e. improve it if necessary , and let people do things their own way by defining extension points ;) I should probably point out that I don't think yours is a bad design, I'm just trying to discern whether the complexity compared to a simpler (and less capable) design really is worth it ;) I'll reply this part later today ... -- Regards, Olemis. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Feb 22, 2012 at 11:51:09AM -0500, Olemis Lang wrote: On Tue, Feb 21, 2012 at 4:38 PM, Magnus Therning mag...@therning.org wrote: The options I see then is that each function comes with its own admin page, or that each function can hook into an admin page. Both of these are more involved. I was thinking of doing something somehow different . Focus on an scenario similar to Bitbucket . You have many repositories each one having hooks admin page where you select «functions» to trigger and, for each active «function» , specify parameters . I don't see why we cannot implement something as simple as that ... especially considering the fact that it's possible to do it the way we want to (i.e. improve it if necessary , and let people do things their own way by defining extension points ;) Well, if there is a single page to administrate *all* «functions», but the «functions» actually come in separate plugins, then each plugin need to somehow hook into that single page. That's what I mean with each function can hook into an admin page above. Not impossible, but more complicated than if all «functions» are contained in a single plugin. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgp1kGJ116rKI.pgp Description: PGP signature
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Feb 22, 2012 at 1:13 PM, Magnus Therning mag...@therning.org wrote: On Wed, Feb 22, 2012 at 11:51:09AM -0500, Olemis Lang wrote: On Tue, Feb 21, 2012 at 4:38 PM, Magnus Therning mag...@therning.org wrote: The options I see then is that each function comes with its own admin page, or that each function can hook into an admin page. Both of these are more involved. I was thinking of doing something somehow different . Focus on an scenario similar to Bitbucket . You have many repositories each one having hooks admin page where you select «functions» to trigger and, for each active «function» , specify parameters . I don't see why we cannot implement something as simple as that ... especially considering the fact that it's possible to do it the way we want to (i.e. improve it if necessary , and let people do things their own way by defining extension points ;) Well, if there is a single page to administrate *all* «functions», but the «functions» actually come in separate plugins, then each plugin need to somehow hook into that single page. That's what I mean with each function can hook into an admin page above. Not impossible, but more complicated than if all «functions» are contained in a single plugin. Now I c your point . Maybe I didn't understand your idea in first place . ;) -- Regards, Olemis Facebook = http://www.facebook.com/olemis Twitter = http://www.twitter.com/olemislc (@olemislc) Blog ES = http://simelo-es.blogspot.com Blog EN = http://simelo-en.blogspot.com Quora = http://www.quora.com/olemis Youtube = http://youtube.com/user/greatsoftw Featured article : [svn r11148] XmlRpcPlugin: `wiki.getPageHTML()` now supports wiki manipulators that can possibly modify the wiki text content before rendering. With test. http://feedproxy.google.com/~r/simelo-news/~3/jk0kgDl73ss/08d0967ae31a Tweet: yo no puedo creer q haya pasado inadvertido el 1/2/12 12:12 ... @elainediaz2003 no dijo na' ... OMG ! ... much more coming soon ;) #fb Follow @olemislc Reply Retweet 12:59 Feb-01 Get this email app! Get a signature like this. CLICK HERE. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
I've not had much time to look into this lately, but I have a question
about the basic design. Correct me if I'm wrong, but your design
seems to call for a very simple hook to be placed in the VCS hook dir
(e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
then calls back into Trac and implementors of
IRepositoryChangeListener are told about the change, and they call
into all IRepositoryHookSubscribers. Is that correct?
If my understanding is correct, what is the use-case behind this trip
back into Trac and added complexity?
Why not just drop a script into the VCS hook dir which then executes
functions located in a well-known place (e.g.
${svn-repo-dir}/functions/)?
If each function is an executable file that would be very simple to
do. The admin page could then allow activation of functions per
repository. Functions are packaged with the plugin, giving the
system-admin full control over what is available to trac-admins.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning mag...@therning.org wrote:
I've not had much time to look into this lately, but I have a question
about the basic design. Correct me if I'm wrong, but your design
seems to call for a very simple hook to be placed in the VCS hook dir
(e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
then calls back into Trac and implementors of
IRepositoryChangeListener are told about the change, and they call
into all IRepositoryHookSubscribers. Is that correct?
If my understanding is correct, what is the use-case behind this trip
back into Trac and added complexity?
quick reply : the idea is to implement hooks as Trac components . This
also means options , database access , ... will be there for you .
- `IRepositoryChangeListener` is some kind of abstraction layer
handling VCS-specific features to satisfy a uniform interface ...
- ... for `IRepositoryHookSubscribers` which implement the actual
hook behavior .
Why not just drop a script into the VCS hook dir which then executes
functions located in a well-known place (e.g.
${svn-repo-dir}/functions/)?
... maybe ... but different VCS (svn, hg , git ..) deal with hook
context activation in many different ways . So you **should** need
an intermediate layer to bind Trac-specific VCS resources (e.g.
changesets) and hook context information , so as to make those
«functions» work *for every* VCS supported by Trac .
If each function is an executable file that would be very simple to
do. The admin page could then allow activation of functions per
repository. Functions are packaged with the plugin, giving the
system-admin full control over what is available to trac-admins.
the same for Trac components ... isn't it ?
--
Regards,
Olemis
Facebook = http://www.facebook.com/olemis
Twitter = http://www.twitter.com/olemislc (@olemislc)
Blog ES = http://simelo-es.blogspot.com
Blog EN = http://simelo-en.blogspot.com
Quora = http://www.quora.com/olemis
Youtube = http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: yo no puedo creer q haya pasado inadvertido el 1/2/12 12:12 ...
@elainediaz2003 no dijo na' ... OMG ! ... much more coming soon ;) #fb
Follow @olemislc Reply Retweet 12:59 Feb-01
Get this email app!
Get a signature like this. CLICK HERE.
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Tue, Feb 21, 2012 at 14:41, Olemis Lang ole...@gmail.com wrote:
On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning mag...@therning.org wrote:
I've not had much time to look into this lately, but I have a question
about the basic design. Correct me if I'm wrong, but your design
seems to call for a very simple hook to be placed in the VCS hook dir
(e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
then calls back into Trac and implementors of
IRepositoryChangeListener are told about the change, and they call
into all IRepositoryHookSubscribers. Is that correct?
If my understanding is correct, what is the use-case behind this trip
back into Trac and added complexity?
quick reply : the idea is to implement hooks as Trac components . This
also means options , database access , ... will be there for you .
- `IRepositoryChangeListener` is some kind of abstraction layer
handling VCS-specific features to satisfy a uniform interface ...
- ... for `IRepositoryHookSubscribers` which implement the actual
hook behavior .
Good, then it sounds like I've understood your design well enough :)
Why not just drop a script into the VCS hook dir which then executes
functions located in a well-known place (e.g.
${svn-repo-dir}/functions/)?
... maybe ... but different VCS (svn, hg , git ..) deal with hook
context activation in many different ways . So you **should** need
an intermediate layer to bind Trac-specific VCS resources (e.g.
changesets) and hook context information , so as to make those
«functions» work *for every* VCS supported by Trac .
Except that *I* didn't have any functions in mind that actually need
Trac-specific VCS resources. I thought of stuff like
- send email on commit
- send twitter on commit
- tickle a CI server on commit
- ...
If each function is an executable file that would be very simple to
do. The admin page could then allow activation of functions per
repository. Functions are packaged with the plugin, giving the
system-admin full control over what is available to trac-admins.
the same for Trac components ... isn't it ?
Except that writing a Trac component is a bit more involved than
writing a script (in any language you are comfortable with) which
takes a well-specified set of arguments on the command line.
Also, the configuration is probably somewhat more involved if hook
functions are allowed to come as separate Trac plugins.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Tue, Feb 21, 2012 at 9:27 AM, Magnus Therning mag...@therning.org wrote:
On Tue, Feb 21, 2012 at 14:41, Olemis Lang ole...@gmail.com wrote:
On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning mag...@therning.org wrote:
I've not had much time to look into this lately, but I have a question
about the basic design. Correct me if I'm wrong, but your design
seems to call for a very simple hook to be placed in the VCS hook dir
(e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
then calls back into Trac and implementors of
IRepositoryChangeListener are told about the change, and they call
into all IRepositoryHookSubscribers. Is that correct?
If my understanding is correct, what is the use-case behind this trip
back into Trac and added complexity?
quick reply : the idea is to implement hooks as Trac components . This
also means options , database access , ... will be there for you .
- `IRepositoryChangeListener` is some kind of abstraction layer
handling VCS-specific features to satisfy a uniform interface ...
- ... for `IRepositoryHookSubscribers` which implement the actual
hook behavior .
Good, then it sounds like I've understood your design well enough :)
;)
Why not just drop a script into the VCS hook dir which then executes
functions located in a well-known place (e.g.
${svn-repo-dir}/functions/)?
... maybe ... but different VCS (svn, hg , git ..) deal with hook
context activation in many different ways . So you **should** need
an intermediate layer to bind Trac-specific VCS resources (e.g.
changesets) and hook context information , so as to make those
«functions» work *for every* VCS supported by Trac .
Except that *I* didn't have any functions in mind that actually need
Trac-specific VCS resources. I thought of stuff like
- send email on commit
- send twitter on commit
- tickle a CI server on commit
- ...
... if you plan to use commit message , author , ... etc ... then
you'll need access to changeset information in hook context , and then
u'll need the Trac changeset as an abstraction so as to make «the
whole thing» work for any VCS ;)
If each function is an executable file that would be very simple to
do. The admin page could then allow activation of functions per
repository. Functions are packaged with the plugin, giving the
system-admin full control over what is available to trac-admins.
the same for Trac components ... isn't it ?
Except that writing a Trac component is a bit more involved than
writing a script (in any language you are comfortable with) which
takes a well-specified set of arguments on the command line.
In this case , the way to go should be to write a *single* Trac
component *once* , specify an option for the scripts path ... a few
more things (maybe) and there u have it !
Or maybe configure them directly ... using VCS-specific hook config
mechanisms . I mean you have a good reason to integrate this with Trac
, isn't it ?
Also, the configuration is probably somewhat more involved if hook
functions are allowed to come as separate Trac plugins.
Configuration is basically , install enable plugin , activate hook
in hook admin panel , set parameters . You are ready to go ;)
--
Regards,
Olemis
Facebook = http://www.facebook.com/olemis
Twitter = http://www.twitter.com/olemislc (@olemislc)
Blog ES = http://simelo-es.blogspot.com
Blog EN = http://simelo-en.blogspot.com
Quora = http://www.quora.com/olemis
Youtube = http://youtube.com/user/greatsoftw
Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Get a signature like this. CLICK HERE.
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Tue, Feb 21, 2012 at 09:56:25AM -0500, Olemis Lang wrote:
On Tue, Feb 21, 2012 at 9:27 AM, Magnus Therning mag...@therning.org wrote:
On Tue, Feb 21, 2012 at 14:41, Olemis Lang ole...@gmail.com wrote:
On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning mag...@therning.org
wrote:
Why not just drop a script into the VCS hook dir which then executes
functions located in a well-known place (e.g.
${svn-repo-dir}/functions/)?
... maybe ... but different VCS (svn, hg , git ..) deal with hook
context activation in many different ways . So you **should**
need an intermediate layer to bind Trac-specific VCS resources
(e.g. changesets) and hook context information , so as to make
those «functions» work *for every* VCS supported by Trac .
Except that *I* didn't have any functions in mind that actually
need Trac-specific VCS resources. I thought of stuff like
- send email on commit
- send twitter on commit
- tickle a CI server on commit
- ...
... if you plan to use commit message , author , ... etc ... then
you'll need access to changeset information in hook context , and
then u'll need the Trac changeset as an abstraction so as to make
«the whole thing» work for any VCS ;)
Well, I can see it could be useful to have such an abstraction for
some functions, but far from all of them.
If each function is an executable file that would be very
simple to do. The admin page could then allow activation of
functions per repository. Functions are packaged with the
plugin, giving the system-admin full control over what is
available to trac-admins.
the same for Trac components ... isn't it ?
Except that writing a Trac component is a bit more involved than
writing a script (in any language you are comfortable with) which
takes a well-specified set of arguments on the command line.
In this case , the way to go should be to write a *single* Trac
component *once* , specify an option for the scripts path ... a few
more things (maybe) and there u have it ! Or maybe configure them
directly ... using VCS-specific hook config mechanisms . I mean you
have a good reason to integrate this with Trac, isn't it ?
Having a single plugin that basically just deals with configuration of
VCS (a replacement for the default RepositoryAdminPanel class), and
the functions are put in as resources in the plugin's Egg. Adding
further functions is done by adding a shell script (or something else
that's executable) to the Egg. That is, adding a function doesn't
require writing another Trac plugin.
Also, the configuration is probably somewhat more involved if hook
functions are allowed to come as separate Trac plugins.
Configuration is basically , install enable plugin , activate hook
in hook admin panel , set parameters . You are ready to go ;)
I see the *implementation* of the configuration to be more
complicated. I think there are good reasons to be able to enable a
function for a subset of the VCS repos only. I also think there are
good reasons to be able to configure the functions with different
parameters for each VCS repo. The options I see then is that each
function comes with its own admin page, or that each function can hook
into an admin page. Both of these are more involved.
I should probably point out that I don't think yours is a bad design,
I'm just trying to discern whether the complexity compared to a
simpler (and less capable) design really is worth it ;)
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
-- Alan Kay
pgpPrDprb7muI.pgp
Description: PGP signature
Re: [Trac] VCS hook control from Trac web admin?
On Mon, Jan 23, 2012 at 14:48, Olemis Lang ole...@gmail.com wrote: Hi ! On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning mag...@therning.org wrote: I've only found a plugin that allows editing of SVN hooks[^1], but it is unlikely to cut it in our organisation; having users editing scripts that are run on the server will not be well received by the system admins. So, is there some other plugin that gives the user some control (but not full) over the hooks, maybe something along the lines of how github handles hooks? Ideally it should also support both SVN and git. ... well ... I'm the maintainer of RepositoryHookSystemPlugin [1]_ - so far it works mostly in GNU/Linux i.e. better compatibility for Windows is needed - ... even if it's designed to support any type of VCS only SVN is actually implemented at the moment , and I was thinking of adding support for Hg . - it's written for 0.11 - in theory users should not be managing repository hooks, not even doing any other admin task (as they all require at least TRAC_ADMIN permission ;) , unless something like multi-project support is to be used and some users manage a project inside an environment . so my Qs are : - What's the target version of Trac ? 0.12 and later. - Target OS ? Linux - If I move its code to e.g. some Hg repository @ Bitbucket would you consider using that plugin as starting point for your work (rather than starting the whole thing from scratch ;) ? Absolutely, but see my comment below. - maybe you might want to add support in there for Git ;) Yes, git is an important target for me in the medium term. Now to my slightly longer comment after reading about the plugin you pointed me to. First, there are two admins in the system, the system-admin (or root) who has full access to the machine, and trac-admins who has admin rights only on a Trac instance. Beyond this there are also trac-users. Do note that there are no system-users in our setup. They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) No what I'm envisioning is a plugin that works a lot like github's hook functions. On github a set of hook functions are available to the repo admin to choose from. Which functions are available is controlled by the system-admin. A repo-admin then ticks the ones that she/he wants, with some configuration possible, like if a mail is to be sent on commit, where does it get sent, etc. This means the system-admin has full control of what code can possibly get run on the server, while the repo-admin can choose the functions that make sense for each repo. Adding a new function is a bit bureaucratic, but does allow the system-admin to stay in charge. The relationship between system-admin and repo-admins on github mirrors the relationship between system-admin and trac-admins in our organisation. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
Quoting Magnus Therning mag...@therning.org: They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) Just to be sure: Does your Trac run under uid 0 (root)? This would be completely unacceptable, of course. If Trac runs as its own, separated user, the shell scripts still can do harm, but e.g. not kill the system. Uploading plugins can be easily prohibited by setting the plugin dir to 555, very simple. Btw. plugins are only stored in the plugins dir and cannot access data, that the trac user (hopefully not root/0) is not allowed to access. Cheers -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning mag...@therning.org wrote: On Mon, Jan 23, 2012 at 14:48, Olemis Lang ole...@gmail.com wrote: Hi ! On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning mag...@therning.org wrote: I've only found a plugin that allows editing of SVN hooks[^1], but it is unlikely to cut it in our organisation; having users editing scripts that are run on the server will not be well received by the system admins. So, is there some other plugin that gives the user some control (but not full) over the hooks, maybe something along the lines of how github handles hooks? Ideally it should also support both SVN and git. ... well ... I'm the maintainer of RepositoryHookSystemPlugin [1]_ - so far it works mostly in GNU/Linux i.e. better compatibility for Windows is needed - ... even if it's designed to support any type of VCS only SVN is actually implemented at the moment , and I was thinking of adding support for Hg . - it's written for 0.11 - in theory users should not be managing repository hooks, not even doing any other admin task (as they all require at least TRAC_ADMIN permission ;) , unless something like multi-project support is to be used and some users manage a project inside an environment . so my Qs are : - What's the target version of Trac ? 0.12 and later. ... well ... that been said , if you move forward this way then you should also be interested (as I am ;) in adding support for Trac=0.12 (which adds some extra-complexity e.g. multi-repos ;) . - Target OS ? Linux good ... though for Trac=0.12 the underlying reason making it not to work now in Windows should be gone (reduced ?) ;) - If I move its code to e.g. some Hg repository @ Bitbucket would you consider using that plugin as starting point for your work (rather than starting the whole thing from scratch ;) ? Absolutely, but see my comment below. btw ... check this out [2]_ (please contact me in private to grant your Bb user with write access to the patch queue ;) . We can hack a little and work on patches in there so as to experiment for a while without touching the main repos . If it turns out that something useful and generic is built in there then I can request an «upgrade» your status so as to to grant you with commit access to main repos ;) - maybe you might want to add support in there for Git ;) Yes, git is an important target for me in the medium term. :) Now to my slightly longer comment after reading about the plugin you pointed me to. First, there are two admins in the system, the system-admin (or root) who has full access to the machine, and trac-admins who has admin rights only on a Trac instance. Beyond this there are also trac-users. Do note that there are no system-users in our setup. common case ;) you should have more control over this once multi-project support will be ready ... but it's not yet They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. that's exactly the goal of the plugin , to implement components inside a Trac environment so as to allow for hook customization but without full access to VCS-specific hook machinery ;) (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. ... if you allow doing this then you have a more serious security issue as this is something happening beyond the scope of the plugin itself . think about it this way : if you manage to prevent trac-admins from uploading plugins (i.e. disable pluginadmin web panel) then only installed Trac components (as determined by system-admins ;) will be available in the admin GUI for trac-admins to choose from . I mean , plugin may be refactored to work this way. Specific hook extensions should be implemented by somebody anyway, but only system-admins will be able to install them in there ;) provided that trac-admin(s) don't have direct access to the system (e.g. via ssh ) . But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) No what I'm envisioning is a plugin that works a lot like github's hook functions. On github a set of hook functions are available to the repo admin to choose from. yes it's similar to Bitbucket as well [3]_ . afaicr , in Bb you could even build your own hooks (a.k.a. brokers) somehow ... let me check where is it ? ... yep [4]_ needless to say I 3 Bb ;) . It's a pythonic-ly djang-ish thingy :) Which functions are available is controlled by the system-admin. A repo-admin then ticks the ones that she/he wants,
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Jan 25, 2012 at 14:48, W. Martin Borgert deba...@debian.org wrote: Quoting Magnus Therning mag...@therning.org: They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) Just to be sure: Does your Trac run under uid 0 (root)? This would be completely unacceptable, of course. If Trac runs as its own, separated user, the shell scripts still can do harm, but e.g. not kill the system. Uploading plugins can be easily prohibited by setting the plugin dir to 555, very simple. Btw. plugins are only stored in the plugins dir and cannot access data, that the trac user (hopefully not root/0) is not allowed to access. *I* don't run the server, and I enjoy being able to upload plugins, so I will assume our system admins are competent enough to not run Apache/Trac/whatever as root, and I will *not* tell them how to prohibit uploading plugins. ;) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
Quoting Magnus Therning mag...@therning.org: I will *not* tell them how to prohibit uploading plugins. ;) Let's hope they don't read this mailing list :~) -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Jan 25, 2012 at 09:20:11AM -0500, Olemis Lang wrote: On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning mag...@therning.org wrote: common case ;) you should have more control over this once multi-project support will be ready ... but it's not yet Would an option be to make it per-repository rather than per-project? I guess the config would be slightly more complicated, but at the same time it might be easier to grasp what's going on as well as slightly more configurable. They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. that's exactly the goal of the plugin , to implement components inside a Trac environment so as to allow for hook customization but without full access to VCS-specific hook machinery ;) Then maybe I'm just confused by the screen-shot, it gives the impression that it's possible to write bash code to be executed on the hook. Which functions are available is controlled by the system-admin. A repo-admin then ticks the ones that she/he wants, with some configuration possible, like if a mail is to be sent on commit, where does it get sent, etc. **similar** to what is displayed in this screenshot [1]_ but without the possibility to edit hook script directly (i.e. only what u see below Listeners on this hook section) ? Ah, I did miss that little detail earlier. Good that you pointed it out. Indeed, it's only that last bit I'd be interested in. I can see a use for making hooks fully editable through the web admin, but it'd be nice if a system-admin could turn it off somehow. This means the system-admin has full control of what code can possibly get run on the server, while the repo-admin can choose the functions that make sense for each repo. Adding a new function is a bit bureaucratic, but does allow the system-admin to stay in charge. ... if we put all the pieces mentioned above together then it should be possible to achieve what u want ... isn't it ? Yes, I'm starting to agree with you :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpDmOuikRYDa.pgp Description: PGP signature
Re: [Trac] VCS hook control from Trac web admin?
Hi ! On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning mag...@therning.org wrote: I've only found a plugin that allows editing of SVN hooks[^1], but it is unlikely to cut it in our organisation; having users editing scripts that are run on the server will not be well received by the system admins. So, is there some other plugin that gives the user some control (but not full) over the hooks, maybe something along the lines of how github handles hooks? Ideally it should also support both SVN and git. ... well ... I'm the maintainer of RepositoryHookSystemPlugin [1]_ - so far it works mostly in GNU/Linux i.e. better compatibility for Windows is needed - ... even if it's designed to support any type of VCS only SVN is actually implemented at the moment , and I was thinking of adding support for Hg . - it's written for 0.11 - in theory users should not be managing repository hooks, not even doing any other admin task (as they all require at least TRAC_ADMIN permission ;) , unless something like multi-project support is to be used and some users manage a project inside an environment . so my Qs are : - What's the target version of Trac ? - Target OS ? - If I move its code to e.g. some Hg repository @ Bitbucket would you consider using that plugin as starting point for your work (rather than starting the whole thing from scratch ;) ? - maybe you might want to add support in there for Git ;) - maybe more later ... ;) I thought I'd ask before I invest too much time in such a plugin myself. wise decision afaict ;) .. [1] RepositoryHookSystemPlugin @ t.h.o (http://trac-hacks.org/wiki/RepositoryHookSystemPlugin) -- Regards, Olemis Facebook = http://www.facebook.com/olemis Twitter = http://www.twitter.com/olemislc (@olemislc) Blog ES = http://simelo-es.blogspot.com Blog EN = http://simelo-en.blogspot.com Quora = http://www.quora.com/olemis Youtube = http://youtube.com/user/greatsoftw Get a signature like this. CLICK HERE. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] VCS hook control from Trac web admin?
I've only found a plugin that allows editing of SVN hooks[^1], but it is unlikely to cut it in our organisation; having users editing scripts that are run on the server will not be well received by the system admins. So, is there some other plugin that gives the user some control (but not full) over the hooks, maybe something along the lines of how github handles hooks? Ideally it should also support both SVN and git. I thought I'd ask before I invest too much time in such a plugin myself. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay [^1]: http://trac-hacks.org/wiki/TracSvnHooksPlugin pgpCmZfZiE7d9.pgp Description: PGP signature
