Add tests for jobs, failed_jobs attributes in lorry specs

When getting information about a lorry spec from WEBAPP (/1.0/lorry/PATH),
we now need it to return two lists of job ids: one for all jobs for that
lorry spec, one with failed jobs only.

We test here the version of the request that returns JSON. The version that
returns HTML is similar (or so we assume), but it's harder to test the HTML
output so we're happy with this.

1 files changed, 54 insertions, 3 deletions

diff --git a/yarns.webapp/040-running-jobs.yarn b/yarns.webapp/040-running-jobs.yarn
index 571afd6..74c6516 100644
--- a/yarns.webapp/040-running-jobs.yarn
+++ b/yarns.webapp/040-running-jobs.yarn
@@ -28,13 +28,18 @@ Then make sure we don't get a job when we request one.
     WHEN admin makes request GET /1.0/list-running-jobs
     THEN response has running_jobs set to []
 
-Add a Lorry spec to the run-queue, and request a job. We still
-shouldn't get a job, since the queue isn't set to run yet.
+Add a Lorry spec to the run-queue, and check that it looks OK.
 
     GIVEN Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
 
     WHEN admin makes request POST /1.0/read-configuration
-    AND admin makes request POST /1.0/give-me-job with host=testhost&pid=123
+    AND admin makes request GET /1.0/lorry/upstream/foo
+    THEN response has jobs set to []
+
+Request a job. We still shouldn't get a job, since the queue isn't set
+to run yet.
+
+    WHEN admin makes request POST /1.0/give-me-job with host=testhost&pid=123
     THEN response has job_id set to null
 
 Enable the queue, and off we go.
@@ -46,6 +51,7 @@ Enable the queue, and off we go.
 
     WHEN admin makes request GET /1.0/lorry/upstream/foo
     THEN response has running_job set to 1
+    AND response has jobs set to [1]
     
     WHEN admin makes request GET /1.0/list-running-jobs
     THEN response has running_jobs set to [1]
@@ -61,6 +67,8 @@ Inform WEBAPP the job is finished.
     THEN response has kill set to false
     WHEN admin makes request GET /1.0/lorry/upstream/foo
     THEN response has running_job set to null
+    AND response has jobs set to [1]
+    AND response has failed_jobs set to []
     WHEN admin makes request GET /1.0/list-running-jobs
     THEN response has running_jobs set to []
 
@@ -69,6 +77,49 @@ Cleanup.
     FINALLY WEBAPP terminates
 
 
+Run a job that fails
+--------------------
+
+Lorry Controller needs to be able to deal with jobs that fail. It also
+needs to be able to list them correctly to the user.
+
+    SCENARIO run a job that fails
+    GIVEN a new git repository in CONFGIT
+    AND an empty lorry-controller.conf in CONFGIT
+    AND lorry-controller.conf in CONFGIT adds lorries *.lorry using prefix upstream
+    AND WEBAPP uses CONFGIT as its configuration directory
+    AND a running WEBAPP
+    AND Lorry file CONFGIT/foo.lorry with {"foo":{"type":"git","url":"git://foo"}}
+    WHEN admin makes request POST /1.0/read-configuration
+    AND admin makes request POST /1.0/start-queue
+
+Initially, the lorry spec should have no jobs or failed jobs listed.
+
+    WHEN admin makes request GET /1.0/lorry/upstream/foo
+    THEN response has jobs set to []
+    AND response has failed_jobs set to []
+
+MINION requests a job.
+
+    WHEN MINION makes request POST /1.0/give-me-job with host=testhost&pid=123
+    THEN response has job_id set to 1
+    AND response has path set to "upstream/foo"
+
+Now, when MINION updates WEBAPP about the job, indicating that it has
+failed, and admin will then see that the lorry spec lists the job in
+failed jobs.
+
+    WHEN MINION makes request POST /1.0/job-update with job_id=1&exit=1
+    AND admin makes request GET /1.0/lorry/upstream/foo
+    THEN response has jobs set to [1]
+    AND response has failed_jobs set to [1]
+
+Cleanup.
+
+    FINALLY WEBAPP terminates
+
+
+
 Limit number of jobs running at the same time
 ---------------------------------------------