Yes, we will probably need this variable in the future. However I would choose different name, probably 'taskotron_item_type', since 'item' is already taken by ansible.

I just have feeling that executor should only execute the task, not do the results reporting. But I don't have strong opinion on the placement. Any thoughts @jskladan @kparal ?

tests.yml is entry point specified by Standard Interface

Sure, why not...

Does "local_action: shell..." support "args: creates=..."? The plan is that we are not going to generate results.yml every time. If the task creates the file (e.g. our generic task like rpmlint), we use that instead.

I just have feeling that executor should only execute the task, not do the results reporting. But >I don't have strong opinion on the placement. Any thoughts @jskladan @kparal ?

Actually, in the non-ansible branch,we do call "resultsdb_directive" in executor.py just with the help of runtask.yml,right? In ansible branch,We can use almost the same logic in our runner.yml,if we have a resultsdb module,but we don't.

tests.yml is entry point specified by Standard Interface

yeah,I know, it's the entry point.it's just that your code makes me feel that you are going to get the tests.yml using koji command,and I don't think we can get the test.yml in that way,though I may be wrong,please correct me, if I am.

Does "local_action: shell..." support "args: creates=..."? The plan is that we are not going to >generate results.yml every time. If the task creates the file (e.g. our generic task like rpmlint), >we use that instead.

Ah,that's the plan,didn't get much clue,as there are only ansible.log and rpmlint_output.log in the artifacts dir.I'm not so familiar with the whole project,is there an easy way to get results.yml without using taskotron_result ?If there isn't ,why don't we only create results.yml here instead?Anyway,local_action dose support "args:creates".

no longer applies