[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