On 4/8/20 1:27 PM, Paul Sokolovsky wrote:

Hello Stevan,

On Wed, 8 Apr 2020 08:31:27 +0200
Stevan Radaković <stevan.radakovic@linaro.org> wrote:

Hey Paul,

I don't want to divert a conversation from the big picture here, but 
here's a query that can help you if I understand your problem
correctly:

https://lite.validation.linaro.org/results/query/+custom?entity=testjob&conditions=testjob__submitter__exact__paul.sokolovsky,testcase__result__exact__Test%20failed,testjob__health__exact__Complete

I appreciate being concise and to the point. And I would need to spend
more homework with that query, but yes, it seems to be just what I
asked for.

And thinking out myself from the link you provided, the answer to a
question "What I'm doing wrong?" would be:

1. I seem to be fixated on "test jobs" and a page
https://lite.validation.linaro.org/scheduler/alljobs, and missing
"test results" and page https://lite.validation.linaro.org/results/ .
And to me it's clear why - what I submit is "job", what fails is
"job", and what I fix is "job", whereas the result page by default
shows only "test suites", with a link to "job" not immediately
visible/clear (requiring one-by-one clickthru to extra pages to find
"job").

2. I had no idea that LAVA query builder hosts actually quite advanced
capabilities. For example, it appears that it allows to encode
database joins concisely (but not exactly intuitively). For example, my
understanding that the query above effectively says "query individual
test cases, find ones with status 'failed', but show not these
testcases, but jobs containing them".

So, while this is already wealth of information to think and play
with, the actual query I'm interested in is:

https://lite.validation.linaro.org/results/query/+custom?entity=testjob&conditions=testjob__submitter__exact__qa-reports-bot,testcase__result__exact__Test%20failed,testjob__health__exact__Complete

(Our jobs are submit-proxied via SQUAD from automated Jenkins builds.)

And that leads me to "502 Proxy Error" (not a rare situation with LAVA
queries on production systems).

Querying by URL is considered a "live" query, i.e. not using caching mechanism in that "usual" queries do. Hence it will time out depending on the data volume in DB and the complexity of the query. That's why we recommend using the cached queries like so:

If you go to the query page, create a Test Job query, then add query conditions described in a URL (test job submitter equals 'qa-reports-bot', test job health equals Complete, test case result equals 'Test failed') and then click on 'Run query' you'll be able to see the results of that query every time in a very timely manner since the query is now cached. I've created an example as well.

You can check out the docs on the topic but also if you need any more clarifications you can reach me on IRC.

Cheers,


So, while I'll need to play with these things more, some tentative
feedback might be:

1. Some queries are more useful than others, and worth being optimized
and be closer to users' fingertips.
2. LAVA query builder is very useful and powerful capability, we should
look for cheap ways to make it easier for users to leverage (inline
hints, tips, more help links, etc.), not a ways to remove it (re:
discussion in https://git.lavasoftware.org/lava/lava/-/issues/394)

It will show you all your jobs which are completed and have at least
one test case failure.

You can use this API call 
https://lite.validation.linaro.org/api/help/#results.run_query to run 
queries from your choice of language and utilize it in any way you
wish.

My preferred language here is a language of visual information in the
GUI with mouse clicks (clicks used sparingly). I simply didn't grow up
to a need to query LAVA via API and process results in advanced ways.
I'm looking just for a basic ways to stop tests falling from my hands,
throwing more API into the mix to jungle with unlikely will help me. 

Thanks!

[]

-- 
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs