[Fuego] testplans and job inter-dependency

Daniel Sangorrin daniel.sangorrin at toshiba.co.jp
Fri Nov 9 08:27:18 UTC 2018


Hello Tim,

I prepared a couple of patches that fix testplans' job
execution order, and allow triggering a new job once
the current one is finished.

[PATCH 1/2] testplans: execute tests in order
[PATCH 2/2] add-jobs: add trigger parameter to specify next job

I put a mention on the commit logs but I wanted to discuss a couple
of questions:
- currently in my patches, the next job is triggered no matter
  if the current job fails or succeeds. That behavior can be
  easily changed. I want to know if you prefer to have a
  new interface to switch the behavior, or just hardwire it to
  a predefined one (e.g. "always continue" or "stop running jobs 
  if one fails").
  I can see cases where you want to stop (eg: if the kernel
  build fails, then the next tests are worthless). On the other
  hand, i can also see cases where you want to go on (e.g.
  when the jobs in the testplan do not really depend on each
  other). 
  If you like the "behavior switch" interface better, then
  I could add a parameter (parallel=True?) to each test in a testplan
  to define that behavior and have a default behavior when
  omitted. Any preferences for the default behavior?
- the second question is related to the interface used when
  adding jobs without a testplan. The current interface 
  (--trigger myjob) only allows you to define one job to
  trigger, but i can add more in the future. The question
  is: if i do --trigger job1,job2,job3, should all those
  jobs be triggered in order (one after the other) or not.
  If we want a "behavior switch" here, the interface could
  become a bit convoluted. For example:
   --trigger job1->job2->job3,job4,job5->job6
  This could be used to define jobs that can run in parallel,
  and jobs that must run in a specific order.

Your feedback is very welcomed.

Thanks,
Daniel
    


  


More information about the Fuego mailing list