summaryrefslogtreecommitdiff
path: root/yarns.webapp/030-queue-management.yarn
blob: a90966aeb2b891c40093ca908c1fc02a714b908f (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
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
Run queue management
====================

This chapter contains tests meant for managing the run-queue in
WEBAPP.

Start and stop job scheduling
-----------------------------

The administrator needs to be able to stop WEBAPP from scheduling any
new jobs, and later to start it again.

    SCENARIO admin can start and stop WEBAPP job scheduling
    GIVEN a running WEBAPP
    WHEN admin makes request GET /1.0/status
    THEN response has running_queue set to true

    WHEN admin makes request POST /1.0/stop-queue
    AND admin makes request GET /1.0/status
    THEN response has running_queue set to false

Further, the state change needs to be persistent across WEBAPP
instances, so we kill the WEBAPP that's currently running, and start a
new one, and verify that the `running-queue` status is still `true`.

    WHEN WEBAPP is terminated
    THEN WEBAPP isn't running

    WHEN WEBAPP is started
    WHEN admin makes request GET /1.0/status
    THEN response has running_queue set to false

Start the queue again.

    WHEN admin makes request POST /1.0/start-queue
    AND admin makes request GET /1.0/status
    THEN response has running_queue set to true

Finally, clean up.

    FINALLY WEBAPP terminates


Read CONFGIT
------------

We need to be able to get Lorry Controller, specifically WEBAPP, to
update its configuration and run-queue from CONFGIT using the
`/1.0/read-configuration` HTTP API request.

First, set up WEBAPP.

    SCENARIO WEBAPP updates its configuration from CONFGIT
    GIVEN a new git repository in CONFGIT
    AND WEBAPP uses CONFGIT as its configuration directory
    AND a running WEBAPP

We'll start with an empty configuration. This is the default state
when WEBAPP has never read its configuration.

    WHEN admin makes request GET /1.0/list-queue
    THEN response has queue set to []

Make WEBAPP read an empty configuration. Or rather, a configuration
that does not match any existing `.lorry` files.

    GIVEN an empty lorry-controller.conf in CONFGIT
    WHEN admin makes request POST /1.0/read-configuration
    AND admin makes request GET /1.0/list-queue
    THEN response has queue set to []

Add a `.lorry` file, with one Lorry spec, and make sure reading the
configuration makes `/list-queue` report it.

    GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
    AND lorry-controller.conf in CONFGIT adds lorries *.lorry using prefix upstream
    WHEN admin makes request POST /1.0/read-configuration
    AND admin makes request GET /1.0/list-queue
    THEN response has queue set to ["upstream/foo"]

If the `.lorry` file is removed, the queue should again become empty.

    GIVEN file CONFGIT/foo.lorry is removed
    WHEN admin makes request POST /1.0/read-configuration
    AND admin makes request GET /1.0/list-queue
    THEN response has queue set to []

Add two Lorries, then make sure they can reordered at will.

    GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
    AND Lorry file CONFGIT/bar.lorry with {"bar":{"type":"git","url":"git://bar"}}
    WHEN admin makes request POST /1.0/read-configuration
    AND admin makes request GET /1.0/list-queue
    THEN response has queue set to ["upstream/bar", "upstream/foo"]

    WHEN admin makes request POST /1.0/move-to-top with path=upstream/foo
    AND admin makes request GET /1.0/list-queue
    THEN response has queue set to ["upstream/foo", "upstream/bar"]

    WHEN admin makes request POST /1.0/move-to-bottom with path=upstream/foo
    AND admin makes request GET /1.0/list-queue
    THEN response has queue set to ["upstream/bar", "upstream/foo"]

If trying to move a lorry that doesn't exist, make sure there's an
appropriate error message.

    WHEN admin makes request POST /1.0/move-to-bottom with path=upstream/alfred
    THEN response matches "upstream/alfred does not exist"

Likewise, if we forget to give a path argument, there should be an
error message.

    WHEN admin makes request POST /1.0/move-to-bottom
    THEN response matches "path.*not given"

Finally, clean up.

    FINALLY WEBAPP terminates