1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
<!-- -*- markdown -*- -->
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
|
