[Fuego] Patches for merge of Toshiba/Sony work
Daniel Sangorrin
daniel.sangorrin at toshiba.co.jp
Wed Mar 22 08:59:39 UTC 2017
Hi Tim,
> > -----Original Message-----
> > From: Bird, Timothy [mailto:Tim.Bird at sony.com]
> >
> > Daniel,
> >
> > Here are some patches for a bunch of work I've done on the merge of the Toshiba
> > and Sony versions of Fuego. This is based off of your bitbucket branch.
...
> >
> > The most significant change is a movement of where and how the logs are stored.
> > All logs for a single run are stored in a single directory:
> > /fuego-rw/logs/<testname>/<target>.<timestamp>.<build_number>/
> >
> > plot data is stored in /fuego-rw/logs/<testname> (plot.data, plot.png, etc.)
It seems that in the new version plot.png is linked. Since plot.png already
conserves history I don't mind not having them separated but I think creating
that link in functions.sh is a bit ugly. I will think about how to express that through
the json extralinks property.
Yesterday, during the AGL meeting, you mentioned a method for distinguishing
between logs from the same test/board but different specs/testplans.
Could you explain it again if you don't mind?
> > I didn't fix anything about flot with this (although the dataload.py module
> > has been updated with new paths for the metric data (for benchmarks)).
Flot isn't working for me. Did you overwrite the plugin?
> > ftc still has a few nagging issues with executing tests independent of a jenkins
> > job (that is, from the command line). However, most things seem to work.
I tried
$ ftc run-test Benchmark.Dhrystone docker testplan_docker
and it seems it worked.
However i tried
$ ftc list-runs
and got no runs. Is this supposed to be correct?
> > A few of the changes I made to ovgen.py don't seem to have made it over
> > to your repository. If a test is missing a spec (including a default spec),
> > it causes problems. I'll try to look at that soon. I don't think any of the
> > tests specified in testplan_docker are affected by this, but I have problems running
> > with the testplan_default plan.
Ok, sorry about that. I thought that testplan_default would be enough, but you are
right because 3rd party tests shouldn't need to add an entry to testplan_default.
> > I didn't do anything with xlsx files, so I'm pretty sure tools you have to create
> > these files will need to be modified with the new log paths.
I haven't checked this yet.
Cheers,
Daniel
> > Sorry to dump and run, but hopefully you can try these changes out.
> > Let me know if stuff breaks.
> > -- Tim
> >
> > P.S. I had to synthesize a BUILD_TIMESTAMP, since Jenkins doesn't put a timestamp
> > in BUILD_ID anymore. The way I'm doing it will not work with post_test separated out
> > (which I think really needs to happen, to isolate it from test_run failures). Several of the
> > tests pass arguments to post_test, so there will have to be a per-test component with
> > data for this somewhere. It was originally in the post_script section in the Jenkins job,
> > but it makes more sense to put this stuff into a test_cleanup() function in the base script, IMHO.
> > I'll give more details when I test some things out.
> >
>
>
>
> _______________________________________________
> Fuego mailing list
> Fuego at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/fuego
More information about the Fuego
mailing list