deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

change delegation to NAME/ style (warning: backward compat breakage)

Browse source 
This is a backward incompatible change.  If you are using delegation and
you upgrade to this version, please do the following:

  * change your gitolite.conf file to use the new syntax (see
    doc/5-delegation.mkd in this commit)

  * for each branch "foo" in the gitolite-admin repo, do this:

        # (on "master" branch)
        git checkout foo -- conf/fragments/foo.conf

  * git add all those new fragments and commit to master

  * delete all the branches on your clone and the server

        # again, for each branch foo
        git branch -D foo
        git push origin :foo
This commit is contained in:
Sitaram Chamarty 2010-01-07 06:56:04 +05:30
parent 08ef3555a1
commit 839027f7a7
2 changed files with 17 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
doc/5-delegation.mkd
View file

@ -63,33 +63,33 @@ You do this by adding branches to the `gitolite-admin` repo:
repo gitolite-admin repo gitolite-admin
RW+ = sitaram RW+ = sitaram
# now add these lines to the config for the admin repo # now add these lines to the config for the admin repo
RW webbrowser_repos = alice RW NAME/conf/fragments/webbrowser_repos = alice
RW webserver_repos = bob RW NAME/conf/fragments/webserver_repos = bob
RW malware_repos = mallory RW NAME/conf/fragments/malware_repos = mallory
This uses gitolite's ability to restrict pushes by file/dir name being changed
-- the syntax you see above ensures that, while "sitaram" does not have any
NAME based restrictions, the other 3 users do. See `conf/example.conf` for
syntax and notes.
As you can see, **for each repo group** you want to delegate authority over, As you can see, **for each repo group** you want to delegate authority over,
there's a **branch with the same name** in the `gitolite-admin` repo. If you there's a rule for a **corresponding file** in `conf/fragments` in the
have write access to that branch, you are allowed to define rules for repos in `gitolite-admin` repo. If you have write access to that file, you are allowed
that repo group. to define rules for repos in that repo group.
In other words, we use gitolite's per-branch permissions to "enforce" the In other words, we use gitolite's file/dir NAME-based permissions to "enforce"
separation between the delegated configs! the separation between the delegated configs!
Here's how to use this in practice: Here's how to use this in practice:
* Alice clones the `gitolite-admin` repo, creates (if not already created) and * Alice clones the `gitolite-admin` repo, and adds a file called
checks out a new branch called `webbrowser_repos`, and adds a file called `conf/fragments/webbrowser_repos.conf`
`conf/fragments/webbrowser_repos.conf` in that branch
* (the rest of the contents of that branch do not matter; she can keep
all the other files or delete all of them -- it doesn't make any
difference. Only that one specific file is used).
* she writes in this file any access control rules for the "firefox" and * she writes in this file any access control rules for the "firefox" and
"lynx" repos. She should not write access rules for any other project -- "lynx" repos. She should not write access rules for any other project --
they will be ignored they will be ignored
* Alice then commits and pushes this branch to the `gitolite-admin` repo * Alice then commits and pushes to the `gitolite-admin` repo
Naturally, a successful push invokes the post-update hook that the admin repo Naturally, a successful push invokes the post-update hook that the admin repo
has, which eventually runs the compile script. The **net effect** is as if has, which eventually runs the compile script. The **net effect** is as if

23
src/ga-post-update-hook
View file

@ -4,28 +4,5 @@
# (the GL_ADMINDIR env var would have been set by gl-auth-command) # (the GL_ADMINDIR env var would have been set by gl-auth-command)
GIT_WORK_TREE=$GL_ADMINDIR git checkout -f master GIT_WORK_TREE=$GL_ADMINDIR git checkout -f master
# remove all fragments. otherwise, you get spurious error messages when you
# take away someone's delegation in the main config but the fragment is still
# hanging around. The ones that are valid will get re-created anyway
rm -rf $GL_ADMINDIR/conf/fragments
# collect all the delegated fragments
mkdir $GL_ADMINDIR/conf/fragments
for br in `git for-each-ref --format='%(refname:short)'`
do
# skip master (duh!)
[ "$br" = "master" ] && continue
# all other branches *should* contain a file called <branchname>.conf
# inside conf/fragments; if so copy it
if git show $br:conf/fragments/$br.conf > /dev/null 2>&1
then
git show $br:conf/fragments/$br.conf > $GL_ADMINDIR/conf/fragments/$br.conf
echo "(extracted $br conf; `wc -l < $GL_ADMINDIR/conf/fragments/$br.conf` lines)"
else
echo " ***** ERROR *****"
echo " branch $br does not contain conf/fragments/$br.conf"
fi
done
cd $GL_ADMINDIR cd $GL_ADMINDIR
$GL_BINDIR/gl-compile-conf $GL_BINDIR/gl-compile-conf