Buildinfo UI - initial design and first iteration

[ncounter]

openSUSE#11694

Initial rendering of all the build-info available at _buildinfo?debug=1 route.
Everything is computed and rendered after parsing the raw data served at that route.

This PR presents the data sliced by the following criteria:

• a summary box wrapping relevant but high level information about the build, including the message error
• a projects box listing all the projects used for the build, with an expand/collapse toggle of the list of the packages fetched from each project
• a dependency relationship box presenting the who-requires-what-from where connection
• the raw data still available at the end of the page for a deeper debugging matter

The data are normalized and manipulated from the buildinfo.js (for the sake of this exercise), as they are already available in the content of the HTML. If this initial iteration will have a follow-up or a spin-off, we should first start thinking about providing data in a different shape on the backend side, and evaluating about serving the data maybe async or even in a lazy-lading behavior for the different pieces.

Short-term: the dependency relationship table could optionally be represented as a tree starting from the direct dependency triggered by the spec file, and indenting by levels of requirements the dependencies. A robust decoding of the names is required for that, as of now the debug build info comes in the shape of:

added perl-Regexp-Common@openSUSE.org:SUSE:SLE-15:GA/pool because of (direct):perl(Regexp::Common)
added glibc@openSUSE.org:SUSE:SLE-15-SP3:GA/pool because of perl:libc.so.6()(64bit)

At the moment the reverse logic is computed and in the page we have the data in the shape of:

(direct):perl(Regexp::Common) requires perl-Regexp-Common from openSUSE.org:SUSE:SLE-15:GA/pool
perl:libc.so.6()(64bit) requires glibc openSUSE.org:SUSE:SLE-15-SP3:GA/pool

Here (direct): stands for it is a direct requirement triggered from the spec file, perl: instead means an intermediate dependency is occurring: perl --> libc.so6()(64bit) --> glibc, something that could be represented as a tree:

perl
   |___libc.so6()(64bit)
             |___ glibc

Long-term: due to the fact dependencies cannot be purely represented as a tree (even if it could already be a valuable representation) but it is more like a graph, an additional d3.js implementation could be a very nice to have, something like https://www.jasondavies.com/d3-dependencies/

Below some screenshot:

• Before: only the raw data
• After:

Summary

Expanded project sources

Dependency relationship

Accessible raw data