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&...
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:
- 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").
- 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&...
(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 https://lite.validation.linaro.org/results/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 https://lite.validation.linaro.org/results/query/~stevan.radakovic/failed-tests/+detail as well.
You can check out the docs on the topic https://docs.lavasoftware.org/lava/lava-queries-charts.html#conditions 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:
- 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!
[]