blob: fb8f61f73767c2be9ac7d6eb528fd0da0a44150c (
plain)
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
|
<!-- -*- 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
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
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
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_
FIXME: Once we have ruleset control, add more here perhaps
|
