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