Update the frontend diffing code to support v2 license scan reports
What does this MR do?
This change ensures the current client side diffing code continues to function as expected while the backend is able to advance the schema of the report artifact. This change adds mapping classes that allows mapping from v2 schema to v1 schema of the license scan report.
Th code in this MR is meant to bridge the gap between the new v2 report format and the old v1 report format. Parsing and diffing the reports on the client side is sub-optimal, couples to the report structure that originates from the deepest part of the system and is not maintainable. Details here.
Effort is underway to move this processing to the server side here.
The change introduced in this MR, is meant to be temporary so that we can move forward with the v2.0 license report format without being blocked by the completion of the conversion to the backend.
The code introduced in this MR is set to expire upon the completion and final release of !17905 (merged).
Screenshots
Tested by diffing a v1 report with a v2 report.
Example v2 report:
{
"version": "2.0",
"licenses": [
{
"id": "MIT",
"name": "MIT License",
"url": "http://spdx.org/licenses/MIT.json",
"count": 1
},
{
"id": "BSD-3-Clause",
"name": "BSD 3-Clause \"New\" or \"Revised\" License",
"url": "http://spdx.org/licenses/BSD-3-Clause.json",
"count": 1
},
{
"id": "LGPL-3.0-only",
"name": "GNU Lesser General Public License v3.0 only",
"url": "http://spdx.org/licenses/LGPL-3.0-only.json",
"count": 6
}
],
"dependencies": [
{
"name": "bundler",
"url": "https://bundler.io",
"description": "The best way to manage your application's dependencies",
"licenses": [ "MIT" ],
"paths": [ "." ]
},
{
"name": "puma",
"url": "http://puma.io",
"description": "Puma is a simple, fast, threaded, and highly concurrent HTTP 1.1 server for Ruby/Rack applications",
"licenses": [ "BSD-3-Clause" ],
"paths": [ "." ]
},
{
"name": "sidekiq",
"url": "",
"description": "",
"licenses": [ "LGPL-3.0-only" ],
"paths": [ "." ]
}
]
}
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry - [-] Documentation created/updated or follow-up review issue created
-
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Performance and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team