gitolite/t/t64-write-able

158 lines
4.6 KiB
Plaintext
Raw Normal View History

# vim: syn=sh:
for bc in 0 1
do
cd $TESTDIR
$TESTDIR/rollback || die "rollback failed"
editrc GL_BIG_CONFIG $bc
editrc GL_WILDREPOS 1
rm -rf /tmp/glt-adc
mkdir /tmp/glt-adc || die "mkdir /tmp/glt-adc failed"
cp ../contrib/adc/* /tmp/glt-adc
echo "\$GL_ADC_PATH = '/tmp/glt-adc';" | addrc
runremote rm -f .gitolite.down
# ----------
name "INTERNAL"
echo "
@leads = u1 u2
@devs = u1 u2 u3 u4
repo foo
RW+ = u1
@gbar = bar/CREATOR/..*
repo @gbar
C = @leads
RW+ = @leads
RW = @devs
" | ugc
expect_push_ok "master -> master"
name "u1 push foo"
cd ~/td
rm -rf foo
runlocal git clone u1:foo
expect "warning: You appear to have cloned an empty repository."
cd foo
mdc; mdc
runlocal git push origin master
expect_push_ok "master -> master"
name "u2 create and push bar/u2/r1"
cd ~/td
runlocal git clone u2:bar/u2/r1
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
expect "Initialized empty Git repository in $TEST_BASE_FULL/bar/u2/r1.git/"
expect "warning: You appear to have cloned an empty repository."
cd r1
mdc; mdc
runlocal git push origin master
expect_push_ok "master -> master"
name "disable entire site"
runremote ls -al .gitolite.down
expect "ls: cannot access .gitolite.down: No such file or directory"
(echo first line; echo second line) | runlocal ssh gitolite able dis
expect "give me '@all' or some reponame"
(echo first line; echo second line) | runlocal ssh gitolite able dis @all
expect "disabling following locations with message:"
expect "first line"
expect "^second line"
expect "/home/$USER"
runremote ls -al .gitolite.down
expect "^.rw------- 1 $USER $USER .. ... .. ..:.. .gitolite.down"
name "u1 push foo fail"
cd ~/td/foo
mdc; mdc
runlocal git push origin master
expect ABORTING
expect "first line"
expect "^second line"
expect "fatal: The remote end hung up unexpectedly"
name "u2 create and push bar/u2/r1 fail"
cd ~/td/r1
mdc; mdc
runlocal git push origin master
expect ABORTING
expect "first line"
expect "^second line"
expect "fatal: The remote end hung up unexpectedly"
name "enable entire site"
runlocal ssh gitolite able en
expect "give me '@all' or some reponame"
runlocal ssh gitolite able en @all
expect "removed ./home/$USER/.gitolite.down."
runremote ls -al .gitolite.down
expect "ls: cannot access .gitolite.down: No such file or directory"
name "u1 push foo"
cd ~/td/foo
mdc; mdc
runlocal git push origin master
expect_push_ok "master -> master"
name "u2 create and push bar/u2/r1"
cd ~/td/r1
mdc; mdc
runlocal git push origin master
expect_push_ok "master -> master"
name "disable foo"
runlocal ssh u1 able dis foo
expect "just .what. are you trying to pull, young man"
echo foo down|runlocal ssh gitolite able dis foo
expect "disabling following locations with message:"
expect "foo down"
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
expect "$TEST_BASE/foo.git"
runremote ls -al $TEST_BASE/foo.git/.gitolite.down
expect ".rw------- 1 $USER $USER .* ..:.. $TEST_BASE/foo.git/.gitolite.down"
name "u1 push foo fail"
cd ~/td/foo
mdc; mdc
runlocal git push origin master
expect ABORTING
expect "foo down"
expect "fatal: The remote end hung up unexpectedly"
name "u2 create and push bar/u2/r1"
cd ~/td/r1
mdc; mdc
runlocal git push origin master
expect_push_ok "master -> master"
name "enable foo, disable bar/u2/r1"
runlocal ssh u1 able en foo
expect "just .what. are you trying to pull, young man"
runlocal ssh gitolite able en foo
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
expect "removed .$TEST_BASE_FULL/foo.git/.gitolite.down."
echo bar/u2/r1 down | runlocal ssh u1 able dis foo
expect "just .what. are you trying to pull, young man"
echo bar/u2/r1 down | runlocal ssh gitolite able dis bar/u2/r1
expect "disabling following locations with message:"
expect "bar/u2/r1 down"
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
expect "$TEST_BASE/bar/u2/r1.git"
runremote ls -al $TEST_BASE/bar/u2/r1.git/.gitolite.down
expect ".rw------- 1 $USER $USER .. ... .. ..:.. $TEST_BASE/bar/u2/r1.git/.gitolite.down"
name "u1 push foo"
cd ~/td/foo
mdc; mdc
runlocal git push origin master
expect_push_ok "master -> master"
name "u2 create and push bar/u2/r1i fail"
cd ~/td/r1
mdc; mdc
runlocal git push origin master
expect ABORTING
expect "bar/u2/r1 down"
expect "fatal: The remote end hung up unexpectedly"
name "INTERNAL"
done