Add behavior to fallback to SBoM license scanning
What does this MR do and why?
Describe in detail what your merge request does and why.
This MR introduces a "fallback" behavior that allows for a project to transition to the new
license database based license scanning. For context, this is required so that enabling the
license_scanning_sbom_scanner
feature does not immediately remove the licenses displayed
for the project dependencies, and affect the outcomes of the license compliance policies set up.
To do this, the new license scanning implementation is only used with the following conditions:
- The
license_scanning_sbom_scanner
feature flag is enabled. - The most recent pipeline with a
cyclonedx
report is newer than the most recent pipeline with alicense_scanning
report. - If a pipeline has both, then it will default to using the
license_scanning
report as the source of truth for licenses.
This has been outlined in Release Post: New License Compliance Scanner (gitlab-com/www-gitlab-com!119232 - merged) as well.
Closes #384936 (closed)
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
TBD
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Set up License Scanning (LS) and Dependency Scanning in a project.
- Identify differences between licenses info provided by:
- legacy implementation
license-scanning
job (Artifact Scanner) - new implementation using SBOMs and License DB (SBOM Scanner)
- legacy implementation
- Enable feature flag for SBOM Scanner for that project.
- Create an MR that target the default branch.
- Check all license features. License info comes from LS artifacts.
- Check
License Compliance
page. - Check
Licenses
tab of pipeline page. - Check MR page. There's no diff in the licenses.
- Check
- In the MR, remove License Scanning from CI config.
- Check MR page.
- License info for the source branch comes from the SBOMs.
- There's a diff in the licenses b/c it's compared with license info coming from LS artifacts.
- Merge the MR into the default branch.
- Check
License Compliance
page.- License info comes from the SBOMs.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #384936 (closed)