[Fuego] JSON schema and examples for Fuego's run.json format
milo.casagrande at linaro.org
Fri Jun 30 08:07:03 UTC 2017
On Fri, Jun 30, 2017 at 9:54 AM, Daniel Sangorrin
<daniel.sangorrin at toshiba.co.jp> wrote:
> Let me explain each item.
>> > - I have removed items that we don't need at the moment (kvm_guest...)
> This part is not strictly needed because the removed items were not "required".
> I removed them for readability so we know which parts are actually meaningful
> or used in Fuego at the moment.
Yeah, that's absolutely fine and necessary I guess.
I don't expect the kernelci test schemas to be uses as is for all use cases.
>> > - I have defined several metadata items specific for fuego
> Here I am using the same keyword "metadata" as in Kernel CI.
> I just added specific properties to metadata that are relevant
> and required for fuego such as the fuego version, the test spec used etc..
> This metadata is important for debugging and replaying a test (e.g. ftc replay run.json).
I think the "metadata" field in kernelci is a free-form object to
store whatever else is necessary, then it's up to the "applications"
(visualization) to make something meaningful with it.
>> > - I have renamed some keys (e.g.: duration_ms instead of time)
> I renamed some items because the meaning in Kernel CI and in Fuego was slightly different.
> For example, in Kernel CI time is a measurement in seconds, but in Fuego we are using milliseconds.
> The idea is that we can still convert Fuego's format to match kernel CI's schema (e.g. multiply by 1000).
This is a good point, and I don't see why we shouldn't change the
format on kernelci side.
I'll have to check, but I don't think it will be a problem, and it makes sense.
> I also changed job_id to job_name and build_id to build_name to reuse Jenkins nomenclature.
> But these are not that important.
Those fields, are tightly coupled with the other parts of kernelci.
Since we have, for each elements stored in the database, an "_id"
field, the "job_id", "build_id", etc... are internal references to the
"_id" field of a "job" resource, etc... They definitely are not
>> > - I have produced a single embedded schema instead of using references to other files
> This is to simplify our code. A single file is easier to manage. I believe Kernel CI
> also supports using single files.
Yeah, you can just "embed" everything into a single JSON object, or
you can split it up, it's mostly up to the test runners (or better,
who has to write the code to dump the result into that format and send
them to kernelci).
> I think I will have to go through some iterations but I think this is a good start, and Kernel CI's
> schemas were really useful to realize some of the possible needs (e.g. multiple measurements
> for a test case).
Glad they could be of help!
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs
More information about the Fuego