Re: [Xen-devel] [OSSTEST PATCH RFC 11/14] Introduce ts-xtf-run

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: [OSSTEST PATCH RFC 11/14] Introduce ts-xtf-run"):
> On Thu, Aug 04, 2016 at 01:19:15PM +0100, Ian Jackson wrote:
> > Please arrange that all problems which ought to cause "record step as
> > `fail' and run no more tests" are handled by:
> >    
> >     - having the code which detects the problem calling die
> >     - that die being caught by a single eval instance
> >     - the code after the eval handling all exceptions that way
> > 
> 
> I will see what I can do regarding this. I'm not very familiar with
> perl, will need to read some docs first.

Sure.  I'm happy to handwave IRL or on IRC if you prefer.

If you want some full-on examples of the use of eval and indeed die,
there are:
  ts-logs-capture      (several smallish examples)
  cs-bisection-step
  Osstest::db_retry    (subrefs, hairy)
  Osstest::Executive::alloc_resources  (one nested inside another)

> > Also there is a latent bug here.  You have xtf_result_defined accept
> > exit statuses 1 and 2, but those are actually not defined exit
> > statuses for the xtf runner.
> 
> FAOD, 1 and 2 are defined xtf exit statuses -- reserved for anything
> python interpreter related. But I think this is going to be moot because
> they are going to be mapped to fail anyway.

What I meant was that exit statuses 1 and 2 mean `it has all gone
horribly wrong'.  They are not supposed to occur.  (They may be
`defined' by the xtf runner spec, but only to reserve them.)

> The XTF exit status is already available in the log, as is the
> osstest result (in substep status line).

Oh good.  Sorry for quibbling, then.

> I guess you want them on the same line? One logm would do.

But, yes, that would be nice.

> > It might be worth recording the environment for each test, for the
> > log, unless the xtf runner prints that.
> 
> It is encoded in test case name.

Jolly good.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel