deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
gitolite/t/t60-daemon-gitweb-via-setperms

171 lines
7.8 KiB
Plaintext
Raw Normal View History

gitweb and daemon should now work even from within setperms modifications: - call setup_gitweb_access and setup_daemon_access from with get_set_perms so when the user sets a perm explicitly it works - in setup_gitweb_access, do not delete description file or gitweb.owner if the repo is wild - make the "fork" adc set gitweb.owner *and* call setperms using GL_WILDREPOS_DEFPERMS - add tests bug fixes: - gl-auth did not even *look* at GL_WILDREPOS_DEFPERMS when auto-"C"reating a wild repo; fixed - setup_gitweb_access did not delete the description file as consistently as it deleted the owner what will NOT work: - removing gitweb permissions does not clear the name from "projects.list". That's complicated, so just wait till the next "compile" to make this happen (thanks to Jefferai for driving this...) ---- mildly puzzling: for some strange reason, after a "git ls-remote ...try3" in t58, instead of not creating a "description" file, we started seeing a 73-byte file containing this message: Unnamed repository; edit this file 'description' to name the repository.
2010-08-20 17:25:23 +02:00
# vim: syn=sh:
for bc in 0 1
do
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
for ais in 0 1
do
cd $TESTDIR
$TESTDIR/rollback || die "rollback failed"
editrc GL_WILDREPOS 1
editrc GL_BIG_CONFIG $bc
echo "\$GL_ALL_INCLUDES_SPECIAL = $ais;" | addrc
name "INTERNAL"
echo "
@leads = u1 u2
@devs = u1 u2 u3 u4
@gbar = bar/CREATOR/..*
repo @gbar
C = @leads
RW+ = @leads
RW = WRITERS @devs
R = READERS
" | ugc
name "nothing set yet"
expect_push_ok "master -> master"
runlocal git ls-remote u1:bar/u1/try1
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try1.git/git-daemon-export-ok
expect "ls: cannot access $TEST_BASE/bar/u1/try1.git/git-daemon-export-ok: No such file or directory"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 0 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 12 .* projects.list"
runremote cat projects.list
notexpect "bar/u1/try1.git"
runlocal git ls-remote u1:bar/u1/try2
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try2.git/git-daemon-export-ok
expect "ls: cannot access $TEST_BASE/bar/u1/try2.git/git-daemon-export-ok: No such file or directory"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 0 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 12 .* projects.list"
runremote cat projects.list
notexpect "bar/u1/try2.git"
name "add daemon access to try1"
echo R daemon | runlocal ssh u1 setperms bar/u1/try1
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
expect "READERS daemon"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try1.git/git-daemon-export-ok
expect "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try1.git/git-daemon-export-ok"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 0 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 12 .* projects.list"
runremote cat projects.list
notexpect "bar/u1/try1.git"
name "add gitweb access to try2"
echo R gitweb | runlocal ssh u1 setperms bar/u1/try2
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
expect "READERS gitweb"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try2.git/git-daemon-export-ok
expect "ls: cannot access $TEST_BASE/bar/u1/try2.git/git-daemon-export-ok: No such file or directory"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 16 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 28 .* projects.list"
runremote cat projects.list
expect "bar/u1/try2.git"
echo "\$GL_WILDREPOS_DEFPERMS = 'R daemon';" | addrc
name "add default daemon access"
runlocal git ls-remote u1:bar/u1/try3
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try3.git/git-daemon-export-ok
expect "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try3.git/git-daemon-export-ok"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 16 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 28 .* projects.list"
runremote cat projects.list
notexpect "bar/u1/try3.git"
name "add default gitweb access"
echo "\$GL_WILDREPOS_DEFPERMS = 'R gitweb';" | addrc
runlocal git ls-remote u1:bar/u1/try4
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try4.git/git-daemon-export-ok
expect "ls: cannot access $TEST_BASE/bar/u1/try4.git/git-daemon-export-ok: No such file or directory"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 32 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 44 .* projects.list"
runremote cat projects.list
expect "bar/u1/try4.git"
name "add default both access"
echo "\$GL_WILDREPOS_DEFPERMS = 'R daemon gitweb';" | addrc
runlocal git ls-remote u1:bar/u1/try5
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try5.git/git-daemon-export-ok
expect "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try5.git/git-daemon-export-ok"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 48 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 60 .* projects.list"
runremote cat projects.list
expect "bar/u1/try5.git"
name "add default both access with @all also"
echo "\$GL_WILDREPOS_DEFPERMS = 'R @all daemon gitweb';" | addrc
runlocal git ls-remote u1:bar/u1/try6
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try6.git/git-daemon-export-ok
expect "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try6.git/git-daemon-export-ok"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 64 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 76 .* projects.list"
runremote cat projects.list
expect "bar/u1/try6.git"
name "remove all from u6"
< /dev/null runlocal ssh u1 setperms bar/u1/try6
runlocal git ls-remote u1:bar/u1/try6
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try6.git/git-daemon-export-ok
expect "ls: cannot access $TEST_BASE/bar/u1/try6.git/git-daemon-export-ok: No such file or directory"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 48 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 60 .* projects.list"
runremote cat projects.list
notexpect "bar/u1/try6.git"
name "set default access to @all only"
echo "\$GL_WILDREPOS_DEFPERMS = 'R @all';" | addrc
runlocal git ls-remote u1:bar/u1/try7
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try7.git/git-daemon-export-ok
[ "$ais" = "0" ] && expect "ls: cannot access $TEST_BASE/bar/u1/try7.git/git-daemon-export-ok: No such file or directory"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try7.git/git-daemon-export-ok"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 48 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 76 .* projects.list"
runremote cat projects.list
[ "$ais" = "0" ] && notexpect "bar/u1/try7.git"
[ "$ais" = "1" ] && expect "bar/u1/try7.git"
name "set default access to daemon only"
echo "\$GL_WILDREPOS_DEFPERMS = 'R daemon';" | addrc
runlocal git ls-remote u1:bar/u1/try8
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try8.git/git-daemon-export-ok
expect "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try8.git/git-daemon-export-ok"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 48 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 76 .* projects.list"
runremote cat projects.list
notexpect "bar/u1/try8.git"
name "set default access to gitweb only"
echo "\$GL_WILDREPOS_DEFPERMS = 'R gitweb';" | addrc
runlocal git ls-remote u1:bar/u1/try9
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
runremote ls -al $TEST_BASE/bar/u1/try9.git/git-daemon-export-ok
expect "ls: cannot access $TEST_BASE/bar/u1/try9.git/git-daemon-export-ok: No such file or directory"
allow @all to also include gitweb and daemon By default, @all does not include gitweb and daemon, but if that's what you want, you can make it happen... see GL_ALL_INCLUDES_SPECIAL variable in conf/example.gitolite.rc
2010-08-24 13:47:41 +02:00
runremote ls -al projects.list
[ "$ais" = "0" ] && expect "gitolite-test gitolite-test 64 .* projects.list"
[ "$ais" = "1" ] && expect "gitolite-test gitolite-test 92 .* projects.list"
runremote cat projects.list
expect "bar/u1/try9.git"
name "INTERNAL"
done
gitweb and daemon should now work even from within setperms modifications: - call setup_gitweb_access and setup_daemon_access from with get_set_perms so when the user sets a perm explicitly it works - in setup_gitweb_access, do not delete description file or gitweb.owner if the repo is wild - make the "fork" adc set gitweb.owner *and* call setperms using GL_WILDREPOS_DEFPERMS - add tests bug fixes: - gl-auth did not even *look* at GL_WILDREPOS_DEFPERMS when auto-"C"reating a wild repo; fixed - setup_gitweb_access did not delete the description file as consistently as it deleted the owner what will NOT work: - removing gitweb permissions does not clear the name from "projects.list". That's complicated, so just wait till the next "compile" to make this happen (thanks to Jefferai for driving this...) ---- mildly puzzling: for some strange reason, after a "git ls-remote ...try3" in t58, instead of not creating a "description" file, we started seeing a 73-byte file containing this message: Unnamed repository; edit this file 'description' to name the repository.
2010-08-20 17:25:23 +02:00
done
Reference in a new issue Copy permalink