gitolite/doc/testing.mkd

49 lines
1.8 KiB
Markdown
Raw Normal View History

2012-03-16 02:54:47 +01:00
# testing gitolite
Here's how to *run* the tests.
<font color="red">**WARNING: they will clobber lots of things in your `$HOME`,
so be sure to use a throwaway userid**.</font>
2012-03-16 02:54:47 +01:00
git clone git://github.com/sitaramc/gitolite
cd gitolite
prove
2012-04-17 03:13:13 +02:00
(Make sure sshd allows incoming ssh to this userid at least from localhost.
Out of scope for this document: sshd config, 'AllowUsers', etc...)
2012-03-16 02:54:47 +01:00
Gitolite's test suite is mostly written using [tsh][] -- the "testing shell".
Take a look at some of the scripts and you will see what it looks like. It
has a few quirks and nuances; if you really care, email me.
[tsh]: http://github.com/sitaramc/tsh
The tests also use a somewhat convoluted system of environment variables in
order to run *entirely* as a local user, without going through ssh at all.
This lets a complete test suite run in about a fifth or less of the time it
would otherwise take.
If you think that defeats the purpose of the testing, you haven't read
[this][auth] yet.
2012-04-17 03:13:13 +02:00
## #trying trying out gitolite
It's easy to take gitolite for a trial run, in ssh mode, and play with all of
its features (except mirroring).
Create a **throw-away userid**, log in to it, then do what the "testing
gitolite" section above says, except instead of running `prove`, you run
`prove t/ssh*`.
When this is done, you get a gitolite installation with 7 gitolite users
("admin", and "u1" through "u6").
Don't forget that the client and the server are all on the same user on the
same machine; we're *simulating* 7 gitolite users using ssh keys! (How?
Maybe `~/.ssh/config` will give you a hint).
URLs look like `user:repo`, so for example you can clone the admin repo by
`git clone admin:gitolite-admin`. Remote commands look like `ssh u1 info`.
So start by cloning the admin repo, and try out whatever you want!