added support for a post-repo-create hook (gl-post-init)
...some people want to run a special function after a repo is created
This commit is contained in:
parent
c18514e213
commit
67a72a3f5b
|
@ -27,3 +27,6 @@ if [ -n "$GL_WILDREPOS_DEFPERMS" ]; then
|
|||
echo "$GL_WILDREPOS_DEFPERMS" > gl-perms
|
||||
fi
|
||||
|
||||
# run gitolite's post-init hook if you can (hook code expects GL_REPO to be set)
|
||||
export GL_REPO; GL_REPO="$to"
|
||||
[ -x hooks/gl-post-init ] && hooks/gl-post-init
|
||||
|
|
150
doc/2-admin.mkd
150
doc/2-admin.mkd
|
@ -4,12 +4,14 @@ In this document:
|
|||
|
||||
* <a href="#_please_read_this_first">please read this first</a>
|
||||
* <a href="#_adding_users_and_repos">adding users and repos</a>
|
||||
* <a href="#_using_hooks">using hooks</a>
|
||||
* <a href="#_custom_hooks">custom hooks</a>
|
||||
* <a href="#_gl_post_init_hook">"gl-post-init" hook</a>
|
||||
* <a href="#_hook_chaining">hook chaining</a>
|
||||
* <a href="#_environment_variables_available_to_hooks">environment variables available to hooks</a>
|
||||
* <a href="#_other_features">other features</a>
|
||||
* <a href="#_moving_pre_existing_repos_into_gitolite">moving pre-existing repos into gitolite</a>
|
||||
* <a href="#_specifying_gitweb_and_daemon_access">specifying gitweb and daemon access</a>
|
||||
* <a href="#_custom_hooks">custom hooks</a>
|
||||
* <a href="#_hook_chaining">hook chaining</a>
|
||||
* <a href="#_environment_variables_available_to_hooks">environment variables available to hooks</a>
|
||||
* <a href="#_custom_git_config">custom git config</a>
|
||||
|
||||
----
|
||||
|
@ -65,6 +67,83 @@ Once you've cloned it, you're ready to add users and repos.
|
|||
automatically be created (empty, but clonable) and users' access will be
|
||||
updated as needed.
|
||||
|
||||
<a name="_using_hooks"></a>
|
||||
|
||||
### using hooks
|
||||
|
||||
<a name="_custom_hooks"></a>
|
||||
|
||||
#### custom hooks
|
||||
|
||||
You can supply your own, custom, hook scripts if you wish. Install gitolite
|
||||
as usual, then:
|
||||
|
||||
* if you installed using "from-client" method (gl-easy-install):
|
||||
* go to the gitolite *source* clone from which you did the original
|
||||
install
|
||||
* add your new hook into "hooks/common"
|
||||
* run src/gl-easy-install with the same arguments as you ran the first
|
||||
time
|
||||
* if you installed using one of the other methods
|
||||
* go to ~/.gitolite/hooks/common on the server and put your new hook
|
||||
there
|
||||
* now run "gl-setup" again
|
||||
|
||||
You can use this procedure to install new hooks as well as to update hooks
|
||||
that you had previously installed.
|
||||
|
||||
**VERY IMPORTANT SECURITY NOTE: the `update` hook in `hooks/common` is what
|
||||
implements all the branch-level permissions in gitolite. If you fiddle with
|
||||
the hooks directory, please make sure you do not mess with this file
|
||||
accidentally, or all your fancy per-branch permissions will stop working.**
|
||||
|
||||
<a name="_gl_post_init_hook"></a>
|
||||
|
||||
#### "gl-post-init" hook
|
||||
|
||||
Sometimes it is necessary to do something whenever a new repo is created. If
|
||||
you need this functionality, just supply a hook called "gl-post-init" with
|
||||
whatever code you want in it.
|
||||
|
||||
<a name="_hook_chaining"></a>
|
||||
|
||||
#### hook chaining
|
||||
|
||||
Gitolite basically takes over the update hook for all repos, but some setups
|
||||
really need the update hook functionality for their own purposes too. In
|
||||
order to allow this, Gitolite now exec's a hook called `update.secondary` when
|
||||
it's own "update" hook is done and everything is ready to go.
|
||||
|
||||
You can create this `update.secondary` hook manually on selected repos on the
|
||||
server, or use the mechanism in the previous section to make gitolite put it
|
||||
on *all* your repos.
|
||||
|
||||
Similarly, gitolite also takes over the post-update hook for the special
|
||||
"gitolite-admin" repo. This hook will also chain to a `post-update.secondary`
|
||||
if such a hook exists. People wishing to do exotic things on the server side
|
||||
when the admin repo is pushed should see doc/shell-games.notes for how to
|
||||
exploit this :-)
|
||||
|
||||
Finally, these names (`update.secondary` and `post-update.secondary`) are
|
||||
merely the defaults. You can change them to anything you want; look in
|
||||
conf/example.gitolite.rc for details.
|
||||
|
||||
<a name="_environment_variables_available_to_hooks"></a>
|
||||
|
||||
#### environment variables available to hooks
|
||||
|
||||
The following environment variables are set, and may be useful for any custom
|
||||
processing you wish to do in your hook code:
|
||||
|
||||
* `GL_USER` -- the user doing the push
|
||||
* `GL_REPO` -- the reponame
|
||||
* `GL_REPO_BASE_ABS` -- the absolute base path where all the repos are kept
|
||||
|
||||
The following variables are also set, but are generally less useful:
|
||||
|
||||
* `GL_BINDIR` -- where all the binaries live
|
||||
* `GL_ADMINDIR` -- common directory for many gitolite things
|
||||
|
||||
<a name="_other_features"></a>
|
||||
|
||||
### other features
|
||||
|
@ -136,71 +215,6 @@ The "compile" script will keep these files consistent with the config settings
|
|||
-- this includes removing such settings/files if you remove "read" permissions
|
||||
for the special usernames or remove the description line.
|
||||
|
||||
<a name="_custom_hooks"></a>
|
||||
|
||||
#### custom hooks
|
||||
|
||||
You can supply your own, custom, hook scripts if you wish. Install gitolite
|
||||
as usual, then:
|
||||
|
||||
* if you installed using "from-client" method (gl-easy-install):
|
||||
* go to the gitolite *source* clone from which you did the original
|
||||
install
|
||||
* add your new hook into "hooks/common"
|
||||
* run src/gl-easy-install with the same arguments as you ran the first
|
||||
time
|
||||
* if you installed using one of the other methods
|
||||
* go to ~/.gitolite/hooks/common on the server and put your new hook
|
||||
there
|
||||
* now run "gl-setup" again
|
||||
|
||||
You can use this procedure to install new hooks as well as to update hooks
|
||||
that you had previously installed.
|
||||
|
||||
**VERY IMPORTANT SECURITY NOTE: the `update` hook in `hooks/common` is what
|
||||
implements all the branch-level permissions in gitolite. If you fiddle with
|
||||
the hooks directory, please make sure you do not mess with this file
|
||||
accidentally, or all your fancy per-branch permissions will stop working.**
|
||||
|
||||
<a name="_hook_chaining"></a>
|
||||
|
||||
#### hook chaining
|
||||
|
||||
Gitolite basically takes over the update hook for all repos, but some setups
|
||||
really need the update hook functionality for their own purposes too. In
|
||||
order to allow this, Gitolite now exec's a hook called `update.secondary` when
|
||||
it's own "update" hook is done and everything is ready to go.
|
||||
|
||||
You can create this `update.secondary` hook manually on selected repos on the
|
||||
server, or use the mechanism in the previous section to make gitolite put it
|
||||
on *all* your repos.
|
||||
|
||||
Similarly, gitolite also takes over the post-update hook for the special
|
||||
"gitolite-admin" repo. This hook will also chain to a `post-update.secondary`
|
||||
if such a hook exists. People wishing to do exotic things on the server side
|
||||
when the admin repo is pushed should see doc/shell-games.notes for how to
|
||||
exploit this :-)
|
||||
|
||||
Finally, these names (`update.secondary` and `post-update.secondary`) are
|
||||
merely the defaults. You can change them to anything you want; look in
|
||||
conf/example.gitolite.rc for details.
|
||||
|
||||
<a name="_environment_variables_available_to_hooks"></a>
|
||||
|
||||
#### environment variables available to hooks
|
||||
|
||||
The following environment variables are set, and may be useful for any custom
|
||||
processing you wish to do in your hook code:
|
||||
|
||||
* `GL_USER` -- the user doing the push
|
||||
* `GL_REPO` -- the reponame
|
||||
* `GL_REPO_BASE_ABS` -- the absolute base path where all the repos are kept
|
||||
|
||||
The following variables are also set, but are generally less useful:
|
||||
|
||||
* `GL_BINDIR` -- where all the binaries live
|
||||
* `GL_ADMINDIR` -- common directory for many gitolite things
|
||||
|
||||
<a name="_custom_git_config"></a>
|
||||
|
||||
#### custom git config
|
||||
|
|
|
@ -294,6 +294,12 @@ sub new_repo
|
|||
# override with the package hooks
|
||||
ln_sf("$GL_PACKAGE_HOOKS/common", "*", "hooks") if $GL_PACKAGE_HOOKS;
|
||||
chmod 0755, "hooks/update";
|
||||
|
||||
# run gitolite's post-init hook if you can. GL_REPO will be correct on a
|
||||
# wildcard create but on a normal (config file) create it will actually be
|
||||
# set to "gitolite-admin", so we need to make sure that for the duration
|
||||
# of the hook it is set correctly.
|
||||
system("env GL_REPO='$repo' hooks/gl-post-init") if -x "hooks/gl-post-init";
|
||||
}
|
||||
|
||||
# ----------------------------------------------------------------------------
|
||||
|
|
Loading…
Reference in a new issue