QA (public) » openQA Project (public)

szarate wrote:

@okurz by:

**AC2:** The user is one and only one question, that is the search term, nothing else    

You mean that the user has one and only one question? :).

I am assuming that the user does not know if he means a testsuite, test module, test step, scenario, product, etc. So I envision the default to be simplistic, like google once was, just a single text field. Ok, you can provide buttons below or above the search bar for advanced stuff, help, customization but let's start simple :)

I guess that for things like this, things would need to be indexed, and that filtering (eg. by build or distri) would be only for names of test suites and scenarios.

What do you want to index? We have git repos -> already indexed, and we have database tables for test suites, so go with that :)

okurz wrote:

szarate wrote:

@okurz by:

**AC2:** The user is one and only one question, that is the search term, nothing else    

You mean that the user has one and only one question? :).

I am assuming that the user does not know if he means a testsuite, test module, test step, scenario, product, etc. So I envision the default to be simplistic, like google once was, just a single text field. Ok, you can provide buttons below or above the search bar for advanced stuff, help, customization but let's start simple :)

While i can agree with being simplistic i don't share re-implementing google.

I guess that for things like this, things would need to be indexed, and that filtering (eg. by build or distri) would be only for names of test suites and scenarios.

What do you want to index? We have git repos -> already indexed, and we have database tables for test suites, so go with that :)

What you propose basically is a killer (as in resources) api endpoint that does a complex query - including search in a git subtree. That's why you might want an index where to search data instead of doing the search directly whenever a user request it.

Oliver just try screen scraping the whole of OpenQA and index every page with Xapian (see https://gitlab.suse.de/alnovak/fast-bzsearch/tree/master). As you are basically asking for a totally unstructured text search which OpenQA has no infrastructure to support, Xapian is really fast and you already know how to screen scrape OpenQA.

I'm really wondering about the idea to search the file system. Beside the problem pointed out by @EDiGiacinto I'm wondering what you want to do once you've found a file in the repository. There's no relation from such a file to a concrete openQA job. But openQA jobs are what the results of that search are supposed to be, right? The acceptance criteria should clarify what kind of results the search is supposed to reveal. I assume visitors of the openQA page would expect to find concrete openQA jobs and if they wanted to search for particular files within a certain test distribution they would use a different kind of search in the first place.

mkittler wrote:

I'm really wondering about the idea to search the file system. Beside the problem pointed out by @EDiGiacinto I'm wondering what you want to do once you've found a file in the repository. There's no relation from such a file to a concrete openQA job. But openQA jobs are what the results of that search are supposed to be, right? The acceptance criteria should clarify what kind of results the search is supposed to reveal. I assume visitors of the openQA page would expect to find concrete openQA jobs and if they wanted to search for particular files within a certain test distribution they would use a different kind of search in the first place.

Not sure where searching the file system comes from. But one of the duplicates was based on this real use case:

• Allison Average looks at #63244.
• The example URLs are dead.
• So she wants to find jobs using qa_run.

Ok, so this ticket is about combining different places to search but not being smart about the relations of the things we might find. So if "nginx" is found in a file of the test distribution that file's path is part of the results but there are still no related openQA jobs returned unless "nginx" shows up within the job settings or job module names.

yes

The initial implementation of the global search UI as well as the underlying REST API got merged - we decided to put it in the experimental namespace for now.

As per discussion, I'm also proposing a follow-up to improve general responsiveness: https://github.com/os-autoinst/openQA/pull/3313

Hello, I would like to propose the following use case.

• I am working with mau-extratests test suite
• I know which perl modules it runs

• I don't know how to find openqa tests to clone that run mau-extratests

• I search for mau-extratests (possibly filtering only for job groups results)

• I get as result, between the others:

The job template: https://openqa.suse.de/admin/job_templates/232
because it contains:

- mau-extratests
- mau-filesystem
[..]
- mau-extratests-desktop:

Thanks!

• Improvements to matches for file contents: os-autoinst/openQA#3317
• Skip arbitrary files in the test root: os-autoinst/openQA#3318

mgrifalconi wrote:

Hello, I would like to propose the following use case.

• I am working with mau-extratests test suite
• I know which perl modules it runs
• I don't know how to find openqa tests to clone that run mau-extratests
• I search for mau-extratests (possibly filtering only for job groups results)
• I get as result, between the others:

The job template: https://openqa.suse.de/admin/job_templates/232
because it contains:

- mau-extratests
- mau-filesystem
[..]
- mau-extratests-desktop:

Thank you for your feedback! I prepared a branch that searches job templates, which I think is what you want:

https://github.com/os-autoinst/openQA/pull/3320

More potentially interesting match types:

• Needles
• Assets
• Bugs

• Job by job module

• I will also propose a PR to handle the testrepo symlink to avoid redundant results.

• @mkittler also suggested we display the type of result, maybe as an icon.

• We should link results, e.g. a job template links to the job group.

cdywan wrote:

• I will also propose a PR to handle the testrepo symlink to avoid redundant results. https://github.com/os-autoinst/openQA/pull/3331

As discussed in the weekly QA tools team meeting a next idea would be to return current job module results similar to what https://github.com/okurz/scripts/blob/master/openqa-db_query_last_use_of_module as mentioned in the description already provides.

I moved out all further, additional ideas into #70840 , please focus on adding the "job module results" only today to be able to resolve this ticket.

https://github.com/os-autoinst/openQA/pull/3353