[Fusionforge-general] Question regarding svntracker / cvstracker and proposal for different approach
AlJeux
aljeux at free.fr
Tue Jun 1 13:28:05 CEST 2010
JL Bond Consulting a écrit :
> On Tue, 2010-06-01 at 11:21 +0200, Roland Mas wrote:
>> I propose a different approach: the scmsvn plugin (and the same
>> applies to other scm* plugins) only adds *one* hook to the repositories
>> it creates, and never touches it afterwards. However, that hook only
>> calls an external script that is in charge of actually doing whatever
>> real actions are required (commit email, link to trackers, trigger CI
>> jobs, whatever). That real script can be regenerated from time to time
>> to take into account new options configured via the web; alternatively,
>> if it can be run with appropriate privileges (database access), it can
>> determine at run-time what actions need to be undertaken and act
>> accordingly.
>>
>> This approach limits the risk of users changing the hooks (if the
>> actual script is outside of the "post-commit" file); also, it's rather
>> extensible since it allows new plugins to add actions without requiring
>> a change in the repositories' hooks, since they only need to provide a
>> bit of code to add into the generated script.
>
> Ok, I see your point and agree. Less mucking around with the subversion
> hooks is best. Also, once the scmsvn is hooked into repositories as they
> are created, then there will be no more delays between
> activating/de-activating other svn related plugins that hook into
> subversion.
>
> So, along those lines, we can have:
>
> $GFORGE/plugins/scmsvn/hooks/run-hooks.ksh
> $GFORGE/plugins/scmsvn/hooks/{start-commit,pre-commit,post-commit,pre-revprop-change,post-revprop-change}->run-hooks.sh (symlinks)
> $GFORGE/plugins/scmsvn/hooks/{start-commit,pre-commit,post-commit,pre-revprop-change,post-revprop-change}.d (directory, apache:apache, 0750)
>
An alternative could be to write your run_hooks in php and then you
would have something like:
<?php
require dirname(__FILE__).'/../../env.inc.php';
require $gfwww.'include/squal_pre.php';
require_once $gfcommon.'include/Plugin.class.php';
require_once $gfcommon.'include/PluginManager.class.php';
setup_plugin_manager() ;
$params['unix_group_name'] = $unix_group_name;
$params['repos'] = $repos;
$params['hooks'] = &$hooks;
plugin_hook('svn_post_commit_hook', $params);
?>
This way, in the svntracker, you just register the plugin to be called
on this hook and have to implement the action in the
svn_post_commit_hook. The result is less code & less scripts.
Alain.
> and run-hooks.ksh can be like:
>
> #!/bin/ksh
> HOOKS_DIR=${0}.d
> for hook in `ls ${HOOKS_DIR}/*`
> do
> if [[ -x $hook ]] ; then
> $hook $@
> fi
> done
>
> The actual subversion hook would simply call, e.g., for post-commit:
> $GFORGE/plugins/scmsvn/hooks/post-commit ${REPOS} ${REV}
>
> Then, other svn related plugins (i.e., svntracker, svncommitemail) can
> simply drop their hook scripts into the appropriate directory under
>
> $GFORGE/plugins/scmsvn/hooks/{start-commit,pre-commit,post-commit,pre-revprop-change,post-revprop-change}.d
>
> This can be done via
> $GFORGE/plugins/${plugin_name}/scripts/${plugin_name}-init.php ???
>
> Would that be good approach?
>
> -Bond
>
> BTW, I like the idea of a task/job scheduler. I suppose that would have
> to be separate process running as daemon perhaps?
>
>
> _______________________________________________
> Fusionforge-general mailing list
> Fusionforge-general at lists.fusionforge.org
> http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
>
More information about the Fusionforge-general
mailing list