| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to store different parameters for different upstream host
types. Currently the troves table has a 'gitlab_token' column for
GitLab upstreams, but in general we might need to have arbitrary
parameters. That column's value is also how we determine the host
type(!).
* Add an explicit 'type' column
* Replace the 'gitlab_token' column with a 'type_params' column
that is a JSON dictionary of type-specific parameters
While we're at it, and since it makes the migration simpler:
* Replace 'troves' table with 'hosts' table
Closes #10.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to replace all uses of "Trove" that should really be
"Downstream Host" or "Upstream Host", except in the database schema
and the REST API (which will probably change later).
* ARCH: Update example code to reflect API name change
* yarns.webapp: Update test descriptions and uses of internal APIs
* units: Update and rename the ls-troves units (although they still
use the ls-troves endpoint for now)
Some references that really are specific to Trove integration are
retained.
Related to #3.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes lorry-controller understand YAML lorry files. If
the file cannot be parsed as YAML then we fall back to attempting
to load it as JSON, before giving up on loading it completely.
The test for broken JSON is modified to use a string which is
invalid for both YAML and JSON.
Change-Id: If83e2e44b38e6fb63dbf0b857e143fdcabab78ac
|
|
|
|
|
|
| |
While we're here, seeing as Adam mentioned it.
Change-Id: I5ddb86c70d76a84cf12fbd4eb91f3802e490d745
|
|
|
|
|
|
|
| |
* Does not explicitely test 'globs' validation.
* Also verifies a missing 'ignore' field does not result in error.
Change-Id: I8140185a485cccdf7086533d3afcc6b7fc5f121b
|
|
|
|
| |
Change-Id: I42fbb8a2f2150cfbc48e07340ecedea76f41639a
|
|
|
|
|
|
|
|
| |
Due to an unwillingness to add another IMPLEMENTS that copypasta'd
the same "MATCH_n = os.environ['MATCH_n']", add this small library
in an attempt to reduce the amount of repitition.
Change-Id: I64dc67ad7bd4c0d7572906168c72b0628a7574db
|
|
|
|
| |
Change-Id: I363b73c897b6728d9938b474f352a11d8554d669
|
|
|
|
| |
Change-Id: I218d4b23fb27526674f96b2f2566bb9ff526f688
|
|
|
|
|
|
|
|
| |
The README lists 'ignore' in the group of optional keys for
trove specifications, yet any attempt to read the configuration
without the key being present would result in a KeyError.
Change-Id: I05121535b970c6d7382def46ffa720209f794633
|
|\
| |
| |
| |
| | |
Reviewed-By: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
| |
|
|\
| |
| |
| |
| | |
Reviewed-by: Sam Thursfield
Reviewed-by: Richard Maw
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We do this by moving the "kill_job" column from the lorries table to the
jobs table, renaming it to "kill" in the process. It makes no sense to
have the flag to kill a specific job in the lorries table.
This avoids the need to reset the flag, since it affects only a specific
job, instead of all jobs of a lorry.
|
|/
|
|
|
|
|
| |
These tests expose a bug: when a job is killed, the flag that
Lorry Controller keeps (kill_job in the lorries table) to remember
that a job is to be killed is never reset, so all future attempts
at running a job for the lorry kill the job at once.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|