047790140a
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.
|
||
|---|---|---|
| .. | ||
| keys | ||
| out | ||
| basic.conf | ||
| cleanout-gitolite | ||
| install-gitolite | ||
| README.mkd | ||
| rollback | ||
| rollback.server | ||
| t-fedora-big-config | ||
| t00-initial | ||
| t01-repo-groups | ||
| t02-user-groups | ||
| t03-branch-permissions | ||
| t03a-branch-permissions | ||
| t04-wild | ||
| t04a-wild-all | ||
| t04a-wild-students | ||
| t05-delegation | ||
| t05a-delegation | ||
| t05b-delegation-wild | ||
| t09-oldtests | ||
| t09a-oldtests | ||
| t50-sequence-test | ||
| t51-personal-branches | ||
| t52-deny-create-ref | ||
| t53-check-info-expand-output | ||
| t54-repo-configs | ||
| t55-repo-configs-wild-without-CREATOR | ||
| t56-repo-configs-wild-with-CREATOR | ||
| t57-daemon-gitweb | ||
| t58-daemon-gitweb-wild | ||
| t59-repo-not-on-disk | ||
| t60-daemon-gitweb-via-setperms | ||
| t61-setperms-groups | ||
| t62-rule-sequences | ||
| t63-perm-cats | ||
| test-driver.sh | ||
| update-gitolite | ||
notes on the testing setup
In this document:
- terminology
- notes and background
- quick instructions for running the test suite
- instructions for adding new tests
terminology
#define PW "patches welcome!"
#define TODO PW
notes and background
-
all testing is done on one machine, using 2 userids
-
test driver exits on the first failed test; no fancy counting here. (PW).
-
installs are done using "gl-easy-install". As such, this test suite is mainly meant for testing the core (access control) functionality, and will not help you test the install/upgrade parts themselves. Those are a lot more difficult to test in an automated fashion, but luckily they also change infrequently and can easily be tested manually when they do. Errors in those are much more visible too. (PW).
-
the test driver has evolved as new scripts were added; you will see that older scripts are a little less sophisticated.
quick instructions for running the test suite
-
create two brand new user IDs: tester and gitolite-test
- these are hard-coded, sorry. (PW)
- give them some passwords
- allow ssh into gitolite-test in
/etc/ssh/sshd_config; preferably use a line likeAllowUsers gitolite-test@127.0.0.1so that no one can ssh in from outside
-
prepare/push a bare clone of gitolite itself on /tmp so that the "tester" userid can grab it painlessly
cd your-gitolite-working-repo git clone --bare $PWD /tmp/gitolite # first time git push -f --all /tmp/gitolite # subsequent times -
"su" to "tester" and clone/fetch the gitolite source:
cd $HOME; git clone /tmp/gitolite # first time cd gitolite; git fetch origin # subsequent times -
checkout and "install" the branch you want to test (install from "tester" userid to "gitolite-test" userid). Example, if you want to test "pu" branch:
git checkout -t origin/pu # if needed git checkout -f pu; git reset --hard origin/pu # subsequent times cd t # THIS IS IMPORTANT (patches welcome, or will be fixed eventually!) ./install-gitolite -
run all or some of the tests
./test-driver.sh # or ./test-driver.sh t51
instructions for adding new tests
(TODO)