gitolite/t/t58-daemon-gitweb-wild

161 lines
6.7 KiB
Plaintext
Raw Normal View History

# vim: syn=sh:
for bc in 0 1
do
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 = @devs
" | ugc
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"
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
notexpect "bar/u1/try1.git"
name "add daemon access"
echo "
R = daemon
" | ugc
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"
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"
name "add one more repo"
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 "gitolite-test gitolite-test .* $TEST_BASE/bar/u1/try2.git/git-daemon-export-ok"
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
notexpect "bar/u1/try1.git"
notexpect "bar/u1/try2.git"
name "add descriptions for try1 and try3 and compile"
echo "
bar/u1/try1 = \"this is bar/u1/try1\"
bar/u1/try3 = \"this is bar/u1/try3\"
" | ugc
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
expect "bar/u1/try1.git"
notexpect "bar/u1/try2.git"
notexpect "bar/u1/try3.git"
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 cat $TEST_BASE/bar/u1/try1.git/description
expect "this is bar/u1/try1"
name "add try3 project"
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"
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
expect "bar/u1/try1.git"
notexpect "bar/u1/try2.git"
notexpect "bar/u1/try3.git"
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 cat $TEST_BASE/bar/u1/try1.git/description
expect "this is 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 cat $TEST_BASE/bar/u1/try3.git/description
expect "Unnamed repository; edit this file 'description' to name the repository."
name "now compile and recheck try3 stuff"
echo "
" | ugc
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"
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
expect "bar/u1/try1.git"
notexpect "bar/u1/try2.git"
expect "bar/u1/try3.git"
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 cat $TEST_BASE/bar/u1/try1.git/description
expect "this is 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 cat $TEST_BASE/bar/u1/try3.git/description
expect "this is bar/u1/try3"
name "add owner for try2 and compile"
echo "
bar/u1/try2 \"owner2\" = \"this is bar/u1/try1\"
" | ugc
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 cat $TEST_BASE/bar/u1/try2.git/config
expect "\[gitweb\]"
expect "owner = owner2"
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/try2.git"
name "add gitweb access to all"
echo "
repo @gbar
R = gitweb
" | ugc
expect_push_ok "master -> master"
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
expect "bar/u1/try1.git"
expect "bar/u1/try2.git"
expect "bar/u1/try3.git"
name "add try4 project"
runlocal git ls-remote u1:bar/u1/try4
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
[ "$ais" = "0" ] && notexpect "testing.git"
[ "$ais" = "1" ] && expect "testing.git"
expect "bar/u1/try1.git"
expect "bar/u1/try2.git"
expect "bar/u1/try3.git"
expect "bar/u1/try4.git"
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 cat $TEST_BASE/bar/u1/try4.git/description
expect "Unnamed repository; edit this file 'description' to name the repository."
name "INTERNAL"
done
done