We've changed the config to be more consistent about "copies" and
"artifacts". This means that "copies" no longer accepts a string, but a
slice of strings. We should bump the config version and blubber version
to make it clear that we're not longer backwards compatible.
Change-Id: Ib68f623cbdcdf0aed74f4fdaec062835748e8eb9
Wrote an OpenAPI 3.0 spec for Blubberoid that provides `x-amples`
entries compatible with service-checker.
The written spec includes basic schema for Blubber config objects that
may be later factored out for use in validation.
Note that OpenAPI 3.0 supports only the v4 draft of the JSON Schema
standard, so some parts of the configuration could not be fully
described. Specifically, v4 does not include the `patternProperties`
definition introduced in the JSON Schema v6 draft that would allow us to
describe `variants` and `runs.environment` and everything beneath.
Blubberoid was refactored slightly to incorporate the new spec as well
as assume JSON as the canonical and default configuration format. It was
also refactored to include a versioned namespace ("v1") after the server
endpoint.
Bug: T205920
Change-Id: I28a341aa503b8920d802715660d4c4d62be45475
JSON seems a better option for a web service in general—other toolchains
in the Docker/Kubernetes space typically prefer YAML for human-edited
configs but convert to JSON on the wire. The "application/json" media
type is well established—unlike "application/yaml" which has no official
assignment by IANA—and is better supported by the OpenAPI (formerly
Swagger) specification.
Added content-type media type validation in the Blubberoid HTTP server
handler, and added a check for `json.Valid(body)` upon receiving a
"application/json" media type. Since any given valid JSON is also valid
YAML, Blubberoid simply does a shallow validation of the JSON body
before punting to `config.ReadConfig` for YAML unmarshalling and
thorough config validation.
Bug: T205920
Change-Id: I970acbde497ed446eb8eed568b1328f8c6f5aa55
Tyler Cipriani
Dan Duvall