-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a "delta-analysis" of only the changed dependencies in a given project #4347
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
First of all, I would like to clarify what we at Porsche understand as a delta scan. Given our legal workflow, we want to build a full report for the first iteration of a project. For any subsequent release / revision, we want the lawyers to revisit only those dependencies which have changed. And by changed, we mean a dependency which has either been freshly introduced or updated with a more recent version. To break it down into use cases, there are three different cases to be considered for a generic delta scan capability, given that you want to build a delta between two iterations (v1 and v2) of the same project:
The third use case is, of course, trivial and IMHO there is nothing to be done for it. For other use cases it is not that trivial. The afformentioned hash calculation can be a quick way to detect the need for a delta scan. But it doesn't solve the problem. We built a simple test case to demonstrate our requirements and the expected result:
This set of depenencies models our baseline project andn would be passed over to the lawyer for review
We have given it a try by using the orth subtract scan result function to build a difference, thus delta, between the two revisions but this didn't deliver a minimal set of add dependecies that we expected. Implementationwise, I think ORT needs to be enhanced with a persistence capability to store the overall scan result per project and revision / timestamp of the scan, so that the difference between project iterations can be determined in the first place. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
We want to report findings from any newly added, changed and deleted dependencies. Just to give you a simple example: Version 1.0: now version 1.1 is coming around which might consist of 110 dependencies with the following structure:
Conclusion: we need to idetify the "delta", meaning we need to be able to report the 30 dependencies that have been either deleted, added or updated. Do we have here the same udnerstanding? I would be very happy if this can be already handled on the analyzer level? |
Is there any road-map designed for enabling "delta-scan" feature for Scan-Code from ORT standpoint?
If yes, please share some information.
Edit by @sschuberth: Please see this comment which clarifies that actually no delta-scan but a delta-analysis is desired. The above mention of "Scan-Code" (sic) is misleading.
The text was updated successfully, but these errors were encountered: