Filter settings by result and groupid #5497
Conversation
This commit provides additional arguments to the job_settings API call in order to get the ids of the jobs which, in additional the key and the its value, it will match the job result per job_group. job_group is intended to be a list for further grouping. The proposal doesnt demostrate a complete solution. Obviously the if statement is under further discussion. An alternative approach could be a separate function, potential named `blocked` but I am not sure for that particular name as it comes from internal SUSE concept and it is not assisiated with openQA. Signed-off-by: ybonatakis <[email protected]>
| $sth = $dbh->prepare( | ||
| if ($filter_results && $groupids) { | ||
| $sth = $dbh->prepare( | ||
| 'SELECT job_id, value FROM job_settings INNER JOIN jobs ON jobs.id=job_settings.job_id WHERE key LIKE ? AND value LIKE ? AND jobs.result = ? AND jobs.group_id = ? AND job_id > ? ORDER BY job_settings.job_id DESC'); | ||
| $sth->execute($key_like, $list_value_like, $filter_results, $groupids, $min_id); | ||
| } else { | ||
| $sth = $dbh->prepare( | ||
| 'SELECT job_id, value FROM job_settings WHERE key LIKE ? AND value LIKE ? AND job_id > ? ORDER BY job_id DESC'); | ||
| $sth->execute($key_like, $list_value_like, $min_id); | ||
|
|
||
| $sth->execute($key_like, $list_value_like, $min_id); | ||
| } |
There was a problem hiding this comment.
The jobgroup id is irrelevant at this stage, if a job matches the search, but it is pre-filtered from the list of results, in the end will hide the data from the user.
Also be aware of the discussion on slack about this route not returning all of the information
| @@ -8,11 +8,18 @@ sub jobs ($self) { | |||
| my $validation = $self->validation; | |||
| $validation->required('key')->like(qr/^[\w\*]+$/); | |||
| $validation->required('list_value')->like(qr/^\w+$/); | |||
| $validation->optional('results')->like(qr/^\w+$/); | |||
| $validation->optional('list_groupids')->like(qr/^[\w\*]+$/); | |||
There was a problem hiding this comment.
For other queries we support "group_glob" and "not_group_globs". Introduing "list_groupids" here looks like a new, inconsistent approach. Also see the second suggestion in https://progress.opensuse.org/issues/131279#Suggestions How about extending the current group_glob support into here?
As alternative, potentially even simpler, see https://progress.opensuse.org/issues/131279#Suggestions number 3 stating "squads" could be mapped into openQA for example with special job settings, e.g. QE Core ensures to trigger all their tests with _SQUAD='QE Core' and then be able to filter by that
There was a problem hiding this comment.
I dont see a straight way to invoke group_glob inside the lib/OpenQA/WebAPI/Controller/API/V1/JobSettings.pm. That is because the variables are tight inside _compose_job_overview_search_args.
There was a problem hiding this comment.
If the code cannot be reused it would at least make sense to keep the design/usage consistent from a user perspective. (And I think this is also mainly what @okurz was asking for.)
This commit provides additional arguments to the job_settings API call in
order to get the ids of the jobs which, in additional the key and the its
value, it will match the job result per job_group. job_group is intended to be
a list for further grouping.
The proposal doesnt demostrate a complete solution.
Obviously the if statement is under further discussion.
An alternative approach could be a separate function, potential named
blockedbut I am not sure for that particular name as it comes frominternal SUSE concept and it is not assisiated with openQA.
https://progress.opensuse.org/issues/131279