Skip unsupported purl type when doing License Scanning
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Why are we doing this work
We previously attempted at limiting the License Scanning execution to only process components with supported purl type and currently do it in two places:
- when fetching the components: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/license_scanning/pipeline_components.rb#L14
- when trying to ingest the license provided within the SBOM report: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/license_scanning/package_licenses.rb#L171
Though, it seems PackageLicenses can actually be called without filtered components and we'll still query the DB to try getting license data for these.
This can cause unecessary overhead on the DB and processing time for the License Scanning feature.
We should ensure all execution flows filter the components based on their purl type and skip all processing for unsupported ones.
Impact
There is no visible user-impact with the current implementation, aside from a potential slower response time of these UI elements (that's just a guess, no number available).
There is a potential performance impact to some workflows relying on the License Scanning feature. For instance, when visiting the MR page and loading the License Compliance widget or visiting the Licenses tab on the pipeline page, the License Scanning feature will do an analysis of the components detected in the branch.
The current implementation will look up the license in our PostresQL DB for all OS packages that have been detected in the branch, though these will always return unknown as we don't have any License information for OS packages in our DB.
Only projects with SBOM reporting OS packages are impacted. The performance cost is not known.
Relevant links
Non-functional requirements
-
Documentation: -
Feature flag: -
Performance: -
Testing: