config ---- View and change configuration for a repository (Takes a repo) ========================================================================= The `config` command allows the repository's configuration file (clod) to be queried and updated from the command line without cloning, editing, and pushing the `refs/gitano/admin` branch. Initially there are three configuration values set for a project, namely that of its owner, description and `HEAD` reference. We can check these out directly, allowing us to verify the initial configuration. However, the config stored is a generic clod configuration so we should also verify everything we can about the behaviour from there. Viewing initial `config` for a repo ----------------------------------- Initially configuration for owner, description and `HEAD` are supplied to a repository when created. `HEAD` is defaulted to `refs/heads/master` but the owner can be set via the person running the create. SCENARIO Viewing initial `config` for a repo GIVEN a standard instance WHEN testinstance adminkey runs create testrepo AND testinstance adminkey runs config testrepo show THEN stderr is empty AND stdout contains project.owner: admin AND stdout contains project.head: refs/heads/master FINALLY the instance is torn down Configuration changes stick --------------------------- When setting configuration variables we expect those values to stick. As such we configure a test repository with a value which is not default and then check for it. SCENARIO Configuration changes stick GIVEN a standard instance WHEN testinstance adminkey runs create testrepo AND testinstance adminkey runs config testrepo set project.head refs/heads/trunk AND testinstance adminkey runs config testrepo show THEN stderr is empty AND stdout contains project.head: refs/heads/trunk When we create a repository it is owned by the creator, however we can change this after it has been created. Since the project's owner is an important part of the metadata, Gitano validates that the username you're setting actually exists... WHEN testinstance adminkey, expecting failure, runs config testrepo set project.owner alice THEN stderr contains Unknown user: alice ... and if it does, then you can set the ownership of the repository GIVEN testinstance, using adminkey, adds a new user alice, with a key called main WHEN testinstance adminkey runs config testrepo set project.owner alice AND testinstance adminkey runs config testrepo show THEN stdout contains project.owner: alice FINALLY the instance is torn down Changes to `HEAD` and description hit the filesystem ---------------------------------------------------- Since the project's description affects things outside of Gitano, verify that when changing configuration, all relevant hook sections are run to update the outside world. SCENARIO Changes to `HEAD` and description hit the filesystem GIVEN a standard instance WHEN testinstance adminkey runs create testrepo AND testinstance adminkey runs config testrepo set project.head refs/heads/trunk AND testinstance adminkey runs config testrepo set project.description foobar THEN server-side testrepo.git file description contains foobar AND server-side testrepo.git file HEAD contains refs/heads/trunk FINALLY the instance is torn down Manipulating list values is possible ------------------------------------ Clod can contain lists in values. Lists are always one-level and can have new items appended... SCENARIO Manipulating list values is possible GIVEN a standard instance WHEN testinstance adminkey runs create testrepo AND testinstance adminkey runs config testrepo set foo.* hello AND testinstance adminkey runs config testrepo set foo.* world AND testinstance adminkey runs config testrepo show THEN stderr is empty AND stdout contains foo.i_1: hello AND stdout contains foo.i_2: world ...and removed in any order... WHEN testinstance adminkey runs config testrepo rm foo.i_1 AND testinstance adminkey runs config testrepo show THEN stderr is empty AND stdout contains foo.i_1: world WHEN testinstance adminkey runs config testrepo rm foo.i_1 AND testinstance adminkey runs config testrepo show THEN stderr is empty AND stdout does not contain foo.i_ FINALLY the instance is torn down FIXME: Now that we have the ability to patch the rules we should add more tests Unknown config values error out on show --------------------------------------- It's essential that the user is told when they've attempted to show a config value which simply does not exist. SCENARIO Showing non-existant configuration values GIVEN a standard instance WHEN testinstance adminkey, expecting failure, runs config gitano-admin show banana THEN stdout is empty AND stderr contains banana