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:
Sitaram Chamarty 2010-09-24 16:19:33 +05:30
parent c18514e213
commit 67a72a3f5b
3 changed files with 91 additions and 68 deletions

View file

@ -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

View file

@ -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

View file

@ -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";
}
# ----------------------------------------------------------------------------