Conversation
e3b5257 to
5eca1e1
Compare
|
One thing that crossed my mind while evaluating https://github.com/mstykow/provenant is: Where / how should we display (potentially different) results from different scanners that were all configured to be run? I'm not saying that we should address that question in this PR already, but it would be important to me that we don't go in a wrong direction here, which then makes adding this kind of information later on unnecessary hard. Probably again something we should try to discuss briefly in a meeting to start with. |
|
If it is possible to run several scanners in an ORT run, then I would think the relation would (or should, if it isn't already) be retained in |
549350d to
61bfdc7
Compare
LGTM UI-wise, thanks! Will leave the code review to @lamppu and @mnonnenmacher.
61bfdc7 to
c8ffde7
Compare
a020e0a to
c8ffde7
Compare
c8ffde7 to
c3c01c4
Compare
Add classes for detected licenses, projects/packages with a detected license, and license detection data. Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Also update its call sites in search component. Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Implement three functions: - one for finding all distinct detected licenses (as SPDX expressions for now), along with the count of projects/packages the license was found from - one for listing all projects/packages that have a detected license - one for all license detections in a project/package Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Implement the UI as three-level table: - top table just lists all detected licenses with package counts - its subrow is another paginated table with all projects/packages from where the license was found - its subrow is the third paginated table which holds the license detection data for the license and project/package Refactor each table view into its own local component, for easier review and maintaining of the three-level table view. Resolves #2074. Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
c3c01c4 to
4dd045b
Compare
This PR adds a view for all license detections from the Scanner to the ORT run details. It is implemented as three endpoints and correspondingly, the UI consists of three tables within each other:
1. Top-level view: all detected licenses with the corresponding package counts
2. All projects/packages that have a detected license
3. License detection data for a license and project/package
NOTE: This is the first, sub-optimal implementation of the feature. It is recognized that the database queries are far from optimal, and even for a relatively small project, the top-level query takes between 1-2 seconds. There are several points for optimization, most notably:
scanner_jobs.ort_run_id.scan_resultstopackage_provenances. The queries need a cross-product betweenscan_resultsandpackage_provenancesviascanner_runs, filtered by theprovenanceCondition()multi-column string comparison (matching URL/hash fields across two tables). There's no direct FK between the two — they're linked by matching denormalized text fields. Adding apackage_provenance_idFK column toscan_resultswould replace this expensive string-comparison filter with an indexed join.