Added by Xiaojing_liu about 4 years ago. Updated about 4 years ago.
0%
Description
Now openQA supports adding new job template in YAML with no test suite. But users cannot trigger this kind of job template by jobs post.
After discussing with Marius, here are two ways to support this feature:
jobs post.jobs post. Since openQA supports adding job template with no test suite, so the parameter TEST should be optional.For 1: the job template ID is invisible for users. So it may not be a good choice.
For 2: if the job template name is null, how could we deal with this situation?
I am wondering what's the purpose of the jobs post.
I guess the purpose is to trigger just one test suite and the job's result does not belong to any job group (when users do not specify a job group id).
Xiaojing_liu wrote:
I am wondering what's the purpose of the
jobs post.
I guess the purpose is to trigger just one test suite and the job's result does not belong to any job group (when users do not specify a job group id).
Correct. The idea behind "jobs post" is to create a single job that has nothing to do with "job templates" and therefore is not necessarily related to job groups. One can specify a group with a parameter, e.g. _GROUP or _GROUP_ID, explicitly however.
So I would say: The feature request is something we do not want to support because jobs post is not meant for this. isos post should be the way to go to interact with job templates. Would it be ok to agree with that?
okurz wrote:
So I would say: The feature request is something we do not want to support because
jobs postis not meant for this.isos postshould be the way to go to interact with job templates. Would it be ok to agree with that?
yes, I am ok with not supporting this feature request.
So, should I set this ticket's status to 'Rejected'?
The idea behind "jobs post" is to create a single job
Yes, but if you specify a MACHINE, PRODUCT, TEST the settings from the machine, product, test suites table are taken. So the idea here was likely to make this work for the new job template settings in a consistent way. So when one specifies e.g. NAME it would in combination with the other variables "make" a job template and settings are taken from it. But I am also not convinced that this is practically very useful so I guess we can reject it for now unless we have better information about the use case.