QA » openQA Project

I checked that we have a way to extract the last build for every job_group

SELECT distinct(group_id), FIRST_VALUE(build) over (partition by group_id order by t_created DESC) FROM jobs WHERE group_id in (1,3);

To have a note, in our code

• the query is generated here https://github.com/os-autoinst/openQA/blob/577b4d3e1011846fb645c04cf611dfe0a7e9afb0/lib/OpenQA/BuildResults.pm#L152
• the visualization template is here https://github.com/os-autoinst/openQA/blob/master/templates/webapi/test/overview.html.ep
• The data processor https://github.com/os-autoinst/openQA/blob/577b4d3e1011846fb645c04cf611dfe0a7e9afb0/lib/OpenQA/WebAPI/Controller/Test.pm#L646

The query in BuildResults.pm is for the "dashboard", that's the index page and group pages. This ticket is about the "test results overview" which has nothing to do with it. Its controller is the function overview within Test.pm (which you've called "data processor", not sure what you mean by that). Btw, I'm usually having a look at WebAPI.pm to check which route is handled where. Ah, I guess I now get it. You mean the links to the test results overview which are present on the dashboard are generated by code in BuuildResults.pm. Not sure whether/how we should alter links on the dashboard for this, though.

It might be a bit tricky to convince DBIx to do a query like the one you've mentioned but rewriting the code to use a native SQL query is possibly also quite an effort because there's already lots of code which is using the DBIx result object.

Yes, I agree with you.
I am exploring an other option is to split the query (that contains different groupsid) and merge the results later
https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Controller/Test.pm#L646

Regarding that,

When a only group is selected, the $search_args used in the query shows

{
  'groupids' => [
                  60
                ],
  'scope' => 'current',
  'build' => 'GM',
  'groupid' => 60
}

and for more than one group

{
  'scope' => 'current',
  'build' => '20210507',
  'groupids' => [
                  1,
                  60
                ],
  'groupid' => 1
}

We can see that the function compose_job_overview_search_args is filling the scope, build and groupid of the first group we select.

The function compose_job_overview_search_args is implemented here
https://github.com/os-autoinst/openQA/blob/3dbc437d2627aec121ce305b9f7cf41a6f4a7067/lib/OpenQA/WebAPI/Plugin/Helpers.pm#L349

And we can see how the groupid and the build is filled
https://github.com/os-autoinst/openQA/blob/3dbc437d2627aec121ce305b9f7cf41a6f4a7067/lib/OpenQA/WebAPI/Plugin/Helpers.pm#L387

Trying to do an approach here https://github.com/os-autoinst/openQA/pull/3925.
Disclaimer: this doesn't work yet, is still a draft

I started a new approach
https://github.com/os-autoinst/openQA/pull/3928

@ilausuch I have deleted the attachment as it might include sensitive internal data. I suggest if possible to use data from openqa.opensuse.org for demonstration purposes as all the relevant data from there is already public so we don't have a problem to share that.

Ok, sorry

I identified a case where doesn't work using only https://github.com/os-autoinst/openQA/pull/3918

http://localhost:9526/tests/overview?groupid=198&groupid=287

Updated: The problem is that the query is only going to show the jobs for only one build. Then if the groupsid we choose has different builds only will be selected one of them.
the problem is in _compose_job_overview_search_args(Helpers.pm) that takes the last_build for the first group_id