[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