Implement test search route and results view

[kalikiana]

• Global search field
• A new search template to render results
• New "Search" controller
• AT3-4 - Search for Perl modules by filename
• AT3-5 - Search Perl module contents
• Results are rendered via a new REST API route

Related: poo#34486

[okurz]

+1

[Martchus]

I imagined the presentation of the results more like on GitHub. So I'm wondering whether the Data table is a good choice here.

And DataTable features like the almost immediate refreshing when entering something to the search input box and filtering might not work well for this kind of extensive search.

The ticket also gives the idea that this search might return a lot of different types of results. I'm also wondering how well this would fit into a column-based structure.

[kalikiana]

I imagined the presentation of the results more like on GitHub. So I'm wondering whether the Data table is a good choice here.

And DataTable features like the almost immediate refreshing when entering something to the search input box and filtering might not work well for this kind of extensive search.

The ticket also gives the idea that this search might return a lot of different types of results. I'm also wondering how well this would fit into a column-based structure.

You're absolutely right. I started off with DataTables thinking it would be a flexible baseline and since we use it a lot and could re-use existing code. Unfortunately it's way more restrictive than I realized.

So I changed it to render a bootstrap-styled list, with a text input at the top. And adding optional fields for different types of results is easy as well.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏

[codecov]

Codecov Report

Merging #3237 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #3237      +/-   ##
==========================================
+ Coverage   91.49%   91.52%   +0.03%     
==========================================
  Files         215      216       +1     
  Lines       13080    13108      +28     
==========================================
+ Hits        11967    11997      +30     
+ Misses       1113     1111       -2     

Impacted Files	Coverage Δ
lib/OpenQA/Setup.pm	96.39% <ø> (ø)
lib/OpenQA/Utils.pm	97.15% <100.00%> (+<0.01%)	⬆️
lib/OpenQA/WebAPI.pm	98.98% <100.00%> (+<0.01%)	⬆️
lib/OpenQA/WebAPI/Controller/API/V1/Search.pm	100.00% <100.00%> (ø)
lib/OpenQA/WebAPI/Controller/Test.pm	96.01% <0.00%> (+0.56%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6bef59e...f8b9039. Read the comment docs.

[okurz]

Have you seen the OBS tests failing related to your changes?

https://build.opensuse.org/package/live_build_log/devel:openQA:TestGithub:PR-3237/openQA/openSUSE_Tumbleweed/x86_64 shows

[ 1114s]     #   Failed test 'No errors'
[ 1114s]     #   at ./t/api/15-search.t line 29.
[ 1114s]     #          got: 'Grep failed: fatal: not a git repository (or any of the parent directories): .git
[ 1114s]     # '
[ 1114s]     #     expected: undef
[ 1114s] 
[ 1114s]     #   Failed test 'Module found'
[ 1114s]     #   at ./t/api/15-search.t line 30.
[ 1114s]     #     Structures begin differing at:
[ 1114s]     #          $got = undef
[ 1114s]     #     $expected = HASH(0x55b4ce66b8a8)

because there is no git in OBS. I think that's something that we should be able to handle in a feasible way. How about just skipping the search in case of no git found and instead reporting the problem that a test repo without git is not supported or something. It might be easier to revert to manually traversing the filesystem. Pick whatever is easier for you to implement.

[okurz]

seems like I missed your last update and only react late, sorry about that.

[Martchus]

I've just tested it locally with the search term "test". 37825 matches found. But at first it looked like nothing was found because there was no loading indication. Then the page was completely unresponsive for several seconds. There should be a loading indication and not everything should be rendered at once (e.g. let the JavaScript engine process events from time to time by splitting the loop or implement some endless scrolling).

[Martchus]

It seems the most important points I've mentioned have been fixed. Especially the loading indication and avoiding the page hangs while rendering is still missing. But these improvements can be done in a follow-up PR.