Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
397 views
in Technique[技术] by (71.8m points)

gitolite - gitolite_admin hooks and mirroring

I'm wondering is there a simple way to install hooks for certain repo using gitolite_admin.

Let's imagine i want to have post-update hook for repo awesome using gitolite_admin repo cloned to my workstation...

#conf/gitolite_conf
repo    awesome
        RW+     =   deployer

contents of post-update:

#!/bin/sh
echo "Post receive-hook => updating Redmine repository"
sudo -u deployer perl -we '`cd /home/deployer/repo/awesome.git && git fetch -q --all`'
See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

You could also look at "repo-specific environment variables"

A special form of the option syntax can be used to set repo-specific environment variables that are visible to gitolite triggers and any git hooks you may install.

For example, let's say you installed a post-update hook that initiates a CI job. By default, of course, this hook will be active for all gitolite-managed repos. However, you only want it to run for some specific repos, say r1, r2, and r4.

To do that, first add this to the gitolite.conf:

repo r1 r2 r4
    option ENV.CI = 1

This creates an environment variable called GL_OPTION_CI with the value 1, before any trigger or hook is invoked.

Note: option names must start with ENV., followed by a sequence of characters composed of alphas, numbers, and the underscore character.

Now the hook running the CI job can easily decide what to do:

# exit if $GL_OPTION_CI is not set
[ -z $GL_OPTION_CI ] && exit

... rest of CI job code as before ...

Of course you can also do the opposite; i.e. decide that the listed repos should not run the CI job but all other repos should:

repo @all
    option ENV.CI = 1

repo r1 r2 r4
    option ENV.CI = ""

That feature is fairly recent (started in commit 999f9cd39, but in this case, completed in commit 63865a16 June 2013 for 3.5.2).
But even you don't have that version, there are other ways to do this using option variables, as the last part of that section explains.

Before this feature was added, you could still do this, by using the gitolite git-config command inside the hook code to test for options and configs set for the repo, like:

if gitolite git-config -q reponame gitolite-options.option-name
then
    ...

And you can use git config variables in the same way.
Or you can use group membership -- see the comments against function "in_group" in "Easy.pm" for details.

# in_group()

# return true if $ENV{GL_USER} is set and is in the given group

# shell equivalent
# if gitolite list-memberships $GL_USER | grep -x $GROUPNAME >/dev/null; then ...

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...