RFC: Taskotron task description format

Kamil Paral kparal at redhat.com
Tue Jan 7 16:23:02 UTC 2014


I've finally read it as well :) Comments below.

> At the moment, that task yaml file for rpmlint [1] looks like:
> 
>   dependencies:
>       - rpmlint
>       - libtaskbot
> 
>   input:
>       args: envr,arch

These arguments are provided by the event trigger, right? So, the event trigger offers a set of arguments and we pick some of them inside "input" section; they can be then used in other sections. Is that right? ('arch' is not actually used anywhere in this demo file).

> 
>   preparation:
>       koji: download $envr

This is great, a preparation phase is exactly what I wanted.

> 
>   execution:
>       python: run_rpmlint.py $workdir

1) You don't actually use $workdir in run_rpmlint.py. I guess that's a bug? Or will we guarantee that CWD is set to $workdir?

2) Can we have multiple execution lines that are run sequentially (or in parallel?) and then consider the aggregate result as a test result? One example is in our outdated rats_install test:
for ks in ['fedora','updates','updates-testing']:
    job.run_test('rats_install', tag=ks, ks=ks, **autoqa_args)
We can of course define this as three separate tests, but sometimes running a few different variants together in a single test run might make sense.

> 
>   post:
>       shell: clean $workdir

How is this supposed to work? 'clean' is not an existing command, is that a keyword?

Will we support running arbitrary shell commands or custom scripts (e.g. './myscript') in this or other phases (like preparation)?

> 
>   report:
>       resultdb: something

I guess it's possible to run and report multiple results from a single test run? I.e. upgradepath checking 20 builds and reporting 20 separate test results.

Can I also report a single result from several execution lines?


I know this is just a demo and we will probably need to discover the answers for many of the questions above collectively. I was trying to think about different use cases a maybe discover some missing ones.


More information about the qa-devel mailing list