Trouble running the analyzer / scanner on a directory not under Version Control #2896
Comments
|
While running a reporter on an ORT result with only a scan result is not forbidden, this is a use-case that is not well tested. The usual (and well tested) workflow is to first create an ORT result with an analyzer result, and then use that as the input for the scanner, which creates another ORT result file that combines the analyzer and scan results. Such "rich" ORT result files should work fine to create reports. |
sschuberth
added
question
|
Maybe you can give me a hint on how to accomplish my goal. What parameters need to be set, so the analyzer will save where the source code was, so that the scanner can find it? |
sschuberth
changed the title
sschuberth
changed the title
sschuberth
changed the title
|
I'm trying to sum up the current status here: An OrtResult contains a Repository that in turn contains a VcsInfo. The latter cannot be set to anything meaningful if the analyzed directory is not under version control. Instead of doing something hacky like setting it to In that context maybe also |
sschuberth
added
enhancement
|
Easy reproducible (need have git) as simulate a fake monorepo: mkdir test
cd test
git clone https://github.com/apple/swift-nio.git
git clone https://github.com/sw360/sw360python.git
ort analyze -i . -o output |
|
I'm having a look at this refactoring. Let me know if you have any more input. |
@sschuberth I noticed that I'm I correct in assuming that Could moving the |
Maybe not "generally", but in the context of this refactoring, yes, if we agree that this refactoring makes sense. I'd esp. like to hear @mnonnenmacher's opinion here.
See above. I'd like to first have a consensus among the core devs that this refactoring is the way to go. |
Moving the `NestedProvenance` data structure to model, allows it to be used within the model without creating a circular dependency between scanner and model. This would enable a future AnalayzerInput class [1] to utilze it and still be placed into the model, where its predecessor `Repostory` is already located. [1] oss-review-toolkit#2896 (comment) Signed-off-by: Jens Keim <[email protected]>
Moving the `NestedProvenance` data structure to model, allows it to be used within the model without creating a circular dependency between scanner and model. This would enable a future `AnalayzerInput` class [1] to utilze it and still be placed into the model, where its predecessor `Repostory` is already located. [1] oss-review-toolkit#2896 (comment) Signed-off-by: Jens Keim <[email protected]>
|
@mnonnenmacher for an overview of changes, I opened a pull request #8724. |
Moving the `NestedProvenance` data structure to model, allows it to be used within the model without creating a circular dependency between scanner and model. This would enable a future `AnalayzerInput` class [1] to utilze it and still be placed into the model, where its predecessor `Repostory` is already located. [1] oss-review-toolkit#2896 (comment) Signed-off-by: Jens Keim <[email protected]>
Moving the `NestedProvenance` data structure to model, allows it to be used within the model without creating a circular dependency between scanner and model. This would enable a future `AnalayzerInput` class [1] to utilze it and still be placed into the model, where its predecessor `Repostory` is already located. [1] oss-review-toolkit#2896 (comment) Signed-off-by: Jens Keim <[email protected]>
Moving the `NestedProvenance` data structure to model, allows it to be used within the model without creating a circular dependency between scanner and model. This would enable a future `AnalayzerInput` class [1] to utilize it and still be placed into the model, where its predecessor `Repostory` is already located. [1] oss-review-toolkit#2896 (comment) Signed-off-by: Jens Keim <[email protected]>
Moving the `NestedProvenance` data structure to model, allows it to be used within the model without creating a circular dependency between scanner and model. This would enable a future `AnalayzerInput` class [1] to utilize it and still be placed into the model, where its predecessor `Repostory` is already located. [1] oss-review-toolkit#2896 (comment) Signed-off-by: Jens Keim <[email protected]>
|
During today's ORT community meeting, we discussed possible solutions for allowing non-vcs projects to be analyzed and scanned. Our use case at HELLA would be to scan non-vcs projects, not just analyze them. This distinction had not been mentioned explicitly up until now. In the light of that use case, @fviernau and @sschuberth advised to abandon the previously suggested course, of allowing
This would allow the PR #8724 will be dropped in favor of this new approach. I will post any updates or findings here. Further input and discussion on this topic is welcome. |
Hello,
I sucessfully created a scan result with the following command. (I used the scancode-toolkit examples.)
cli\build\install\ort\bin\ort scan -p "C:\scancode-toolkit-3.1.1\samples" -o myOutOutput:
If I look at the .yml file, it looks good and contains many licensed.
Now I try to generate any kind of report. My goal is to generate an attribution notice. So I run the command:
cli\build\install\ort\bin\ort report -i myOut\scan-result.yml -o myOutReport -f Excelbut the output shows the error
For -f NoticeSummary, or -f NoticeByPackage OSS-RT seems to work at first glance:
But despite the many licenses in the .yml, the resulting report is empty, i.e. it says:
This project neither contains or depends on any third-party software components.What is the problem, or how can this be fixed?
I attached my scan result for easy reference.
scan-result.yml.txt
The text was updated successfully, but these errors were encountered: