gitolite/t/t59-repo-not-on-disk

121 lines
3.7 KiB
Plaintext
Raw Permalink Normal View History

# vim: syn=sh:
# check basic repo level permissions, including what happens when the repo on
# disk is missing (non-wildcard only)
for bc in 0 1
do
cd $TESTDIR
$TESTDIR/rollback || die "rollback failed"
editrc GL_BIG_CONFIG $bc
name "INTERNAL"
echo "
@g1 = u1 u2
@g2 = u3 u4
@g3 = u5 u6
repo aa
RW+ = tester
RW = @g1
R = @g2
" | ugc
expect_push_ok "master -> master"
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 "remote: Initialized empty Git repository in $TEST_BASE_FULL/aa.git/"
cd ~/td
name "check u1 can auto-create and push"
runlocal git clone u1:aa
expect "Cloning into 'aa'..."
expect "warning: You appear to have cloned an empty repository"
cd ~/td/aa
mdc; mdc; mdc
mdc; mdc; mdc
mdc; mdc; mdc
name "INTERNAL"
runlocal git push origin HEAD
expect "To u1:aa"
expect "\* \[new branch\] HEAD -> master"
expect_push_ok "HEAD -> master"
name "check u1 cant rewind"
runlocal git reset --hard HEAD^
runlocal git push origin +master
expect "remote: + refs/heads/master aa u1 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/master"
expect "\[remote rejected\] master -> master (hook declined)"
cd ~/td
rm -rf aa
name "check tester can rewind"
runlocal git clone gitolite:aa
expect "Cloning into 'aa'..."
cd aa
runlocal git reset --hard HEAD^
runlocal git push origin +master
expect_push_ok "master -> master (forced update)"
cd ~/td
rm -rf aa
name "check u4 can only read"
runlocal git clone u4:aa
expect "Cloning into 'aa'..."
cd aa
mdc; mdc; mdc
runlocal git push origin master
expect "W access for aa DENIED to u4"
cd ~/td
rm -rf aa
name "check u6 cant even read"
runlocal git clone u6:aa
expect "Cloning into 'aa'..."
expect "R access for aa DENIED to u6"
# now the same thing with the repo-on-disk missing
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 rm -rf $TEST_BASE/aa.git
cd ~/td
name "repo on disk missing: u1"
runlocal git clone u1:aa
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
[ "$bc" = "0" ] && expect "fatal: '$TEST_BASE_FULL/aa.git' does not appear to be a git repository"
[ "$bc" = "1" ] && expect "R access for aa DENIED to u1"
[ "$bc" = "1" ] && expect "Or there may be no repository at the given path. Did you spell it correctly?"
name "repo on disk missing: tester"
runlocal git clone gitolite:aa
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
[ "$bc" = "0" ] && expect "fatal: '$TEST_BASE_FULL/aa.git' does not appear to be a git repository"
[ "$bc" = "1" ] && expect "R access for aa DENIED to tester"
[ "$bc" = "1" ] && expect "Or there may be no repository at the given path. Did you spell it correctly?"
name "repo on disk missing: u4"
runlocal git clone u4:aa
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
[ "$bc" = "0" ] && expect "fatal: '$TEST_BASE_FULL/aa.git' does not appear to be a git repository"
[ "$bc" = "1" ] && expect "R access for aa DENIED to u4"
[ "$bc" = "1" ] && expect "Or there may be no repository at the given path. Did you spell it correctly?"
name "repo on disk missing: u6"
runlocal git clone u6:aa
expect "R access for aa DENIED to u6"
# now the same thing with a repo that is not even in the config
cd ~/td
name "repo on disk missing: u1"
runlocal git clone u1:bb
expect "R access for bb DENIED to u1"
name "repo on disk missing: tester"
runlocal git clone gitolite:bb
expect "R access for bb DENIED to tester"
name "repo on disk missing: u4"
runlocal git clone u4:bb
expect "R access for bb DENIED to u4"
name "repo on disk missing: u6"
runlocal git clone u6:bb
expect "R access for bb DENIED to u6"
name INTERNAL
done