Basic tests for Gitano ====================== In these basic tests for Gitano we start life by creating a standard installation and verifying some of the very basics of Gitano's core functionality. Basic behaviour --------------- In this scenario we verify that we can create a standard instance and then clone the `gitano-admin` repository. Once we've done that we also verify that we can create a user, give it an ssh key, that the user's creation is reflected in the `gitano-admin` repository and that we can remove the user and the removal is also reflected. SCENARIO Verification of basic behaviour Step 1 is to create a standard instance and clone `gitano-admin` GIVEN a standard instance WHEN testinstance, using adminkey, clones gitano-admin as gitano-admin THEN testinstance has a clone of gitano-admin Next we create the user (alice) and verify that `gitano-admin` shows her. In this scenario we're creating alice's user long-hand to show how it can be done, but in future we will use a shortcut GIVEN instead. GIVEN a unix user called alice AND alice has keys called main WHEN testinstance, using adminkey, adds user alice, using alice main AND git pull happens in testinstance gitano-admin THEN testinstance gitano-admin has a file called users/alice/user.conf AND testinstance gitano-admin has a file called users/alice/default.key Finally we remove that user and verify that `gitano-admin` reflects that too. WHEN testinstance, using adminkey, deletes user alice AND git pull happens in testinstance gitano-admin THEN testinstance gitano-admin has no file called users/alice/user.conf AND testinstance gitano-admin has no file called users/alice/default.key FINALLY the instance is torn down Users can see what groups they are in ------------------------------------- In this scenario we take a standard instance and ensure that the `testinstance` user can access their user information (their `whoami` output) and that information lists the `gitano-admin` group which they should be a member of. SCENARIO whoami shows the gitano-admin group GIVEN a standard instance WHEN testinstance adminkey runs whoami THEN stdout contains gitano-admin Then, just to be sure, we create a new user and ensure that it does not have membership of `gitano-admin` GIVEN testinstance, using adminkey, adds a new user alice, with a key called main WHEN alice main runs whoami THEN stdout does not contain gitano-admin FINALLY the instance is torn down Non-admin users cannot see the `gitano-admin` repository -------------------------------------------------------- In this scenario we take a standard instance, add a user to it, and verify that when the new user runs 'ls' it doesn't get to see `gitano-admin` but that the `testinstance` user gets to see it and has `RW` privs. SCENARIO ls will not show repositories you have no access to GIVEN a standard instance AND testinstance, using adminkey, adds a new user alice, with a key called main WHEN alice main runs ls THEN stdout does not contain gitano-admin WHEN testinstance adminkey runs ls THEN stdout contains RW \ gitano-admin FINALLY the instance is torn down Basic repository creation ------------------------- In a default configuration, the only user who will be able to create repositories. However creation can hand off ownership which means that we can test that a new user who has a repository created for them can see it in ls. SCENARIO delegated repository creation works GIVEN a standard instance AND testinstance, using adminkey, adds a new user alice, with a key called main WHEN testinstance adminkey runs create somerepo alice AND alice main runs ls THEN stdout contains RW \ somerepo And just to check, if the `testinstance` user created a non-delegated repo then the `alice` user cannot see it. WHEN testinstance adminkey runs create anotherrepo AND testinstance adminkey runs ls THEN stdout contains RW \ anotherrepo WHEN alice main runs ls THEN stdout does not contain anotherrepo FINALLY the instance is torn down Basic command handling ---------------------- Users interact by running commands. Normally when using SSH without a command you get a shell, however this isn't the standard use of SSH, so when you haven't provided a command you get an error message. SCENARIO handling empty commands GIVEN a standard instance WHEN testinstance adminkey, expecting failure, runs THEN stderr contains FATAL: No command provided, cannot continue FINALLY the instance is torn down Bypass user alerting -------------------- When the bypass user is used, Gitano should whine strongly in order to discourage the human doing this. SCENARIO using bypass warns loudly GIVEN a standard instance WHEN testinstance bypasskey runs ls THEN the output contains ALERT AND the output contains DO NOT DO THIS AND the output contains DANGER AND the output contains VERY RISKY GIVEN testinstance using adminkey has patched gitano-admin with post-receive-alert.patch WHEN testinstance using adminkey clones gitano-admin.git as gitano-admin AND testinstance using adminkey pushes an empty commit in gitano-admin WHEN testinstance using bypasskey pushes an empty commit in gitano-admin THEN the output contains PERIL AND the output contains CRITICAL FAILURE AND the output does not contain XYZZY FINALLY the instance is torn down