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
|
Handling of remote Troves
=========================
This chapter has tests for WEBAPP's handling of remote Troves: getting
the listing of repositories to mirror from the Trove, and creating
entries in the run-queue for them.
Reading a remote Trove specification from CONFGIT
-------------------------------------------------
When there's a `troves` section in the Lorry Controller configuration
file, the WEBAPP should include that in the list of Troves when
reported.
SCENARIO a Trove is listed in CONFGIT
GIVEN a new git repository in CONFGIT
AND an empty lorry-controller.conf in CONFGIT
AND WEBAPP uses CONFGIT as its configuration directory
Note that we need to fake a remote Trove, using static files, to keep
test setup simpler.
AND WEBAPP fakes Trove example-trove
AND a running WEBAPP
Initially WEBAPP should report no known Troves, and have an empty
run-queue.
WHEN admin makes request GET /1.0/status
THEN response has run_queue set to []
AND response has troves set to []
Let's add a `troves` section to the configuration file. After WEBAPP
reads that, it should list the added Trove in status.
GIVEN lorry-controller.conf in CONFGIT adds trove example-trove
AND lorry-controller.conf in CONFGIT has prefixmap example:example for example-trove
WHEN admin makes request POST /1.0/read-configuration
AND admin makes request GET /1.0/status
THEN response has troves item 0 field trovehost set to "example-trove"
However, this should not have made WEBAPP to fetch a new list of
repositories from the remote Trove.
THEN response has run_queue set to []
If we tell WEBAPP to fetch the list, we should see repositories.
GIVEN remote Trove example-trove has repository example/foo
WHEN admin makes request POST /1.0/ls-troves
AND admin makes request GET /1.0/list-queue
THEN response has queue set to ["example/foo"]
If we re-read the configuration again, without any changes to it or to
the fake Trove's repository list, the same Troves and Lorry specs
should remain in STATEDB. (It wasn't always thus, due to a bug.)
WHEN admin makes request POST /1.0/read-configuration
AND admin makes request GET /1.0/status
THEN response has troves item 0 field trovehost set to "example-trove"
WHEN admin makes request GET /1.0/list-queue
THEN response has queue set to ["example/foo"]
If the Trove deletes a repository, we should still keep it locally, to
avoid disasters. However, it will be removed from the Trove's STATEDB,
and it won't be lorried anymore.
GIVEN remote Trove example-trove doesn't have repository example/foo
WHEN admin makes request POST /1.0/ls-troves
AND admin makes request GET /1.0/list-queue
THEN response has queue set to []
Cleanup.
FINALLY WEBAPP terminates
|
