From 67a72a3f5b3b28bc685d34521b3037832a65bac1 Mon Sep 17 00:00:00 2001 From: Sitaram Chamarty Date: Fri, 24 Sep 2010 16:19:33 +0530 Subject: [PATCH] added support for a post-repo-create hook (gl-post-init) ...some people want to run a special function after a repo is created --- contrib/adc/fork | 3 + doc/2-admin.mkd | 150 ++++++++++++++++++++++++++--------------------- src/gitolite.pm | 6 ++ 3 files changed, 91 insertions(+), 68 deletions(-) diff --git a/contrib/adc/fork b/contrib/adc/fork index 70deb4c..224be36 100755 --- a/contrib/adc/fork +++ b/contrib/adc/fork @@ -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 diff --git a/doc/2-admin.mkd b/doc/2-admin.mkd index d250077..c7e9efb 100644 --- a/doc/2-admin.mkd +++ b/doc/2-admin.mkd @@ -4,12 +4,14 @@ In this document: * please read this first * adding users and repos + * using hooks + * custom hooks + * "gl-post-init" hook + * hook chaining + * environment variables available to hooks * other features * moving pre-existing repos into gitolite * specifying gitweb and daemon access - * custom hooks - * hook chaining - * environment variables available to hooks * custom git config ---- @@ -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. + + +### using hooks + + + +#### 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.** + + + +#### "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. + + + +#### 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. + + + +#### 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 + ### 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. - - -#### 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.** - - - -#### 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. - - - -#### 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 - #### custom git config diff --git a/src/gitolite.pm b/src/gitolite.pm index cef3bf0..9733cf8 100644 --- a/src/gitolite.pm +++ b/src/gitolite.pm @@ -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"; } # ----------------------------------------------------------------------------