Open bulwahn opened 3 years ago
@bulwahn CodeChecker from the previous 6.16.0 release supports storage of multiple report directory with one command:
CodeChecker store -n myrun ./report_dir1 ./report_dir2
. For example you can use it if you run the analysis with different configurations (e.g.: cut / non-ctu) but you want to create only a single run.
On the gui if you click on a report there will be an Analysis info
button which will show exactly from which analysis command does this report comes from. Isn't it enough for you?
By the way this issue is the same as #561.
I think storing from multiple configurations into one single run could be sufficient, but we would also need to be able to filter results based on the Analysis info then, tagging each report would be more flexible, of course.
This issue here is a duplicate to #561, here it is motivated by a specific use case.
Is your feature request related to a problem? Please describe. The linux-kernel build is highly configurable. Every stakeholder interested in tracking static analysis reports has stakes in a slightly different kernel configuration. Hence, the report of interest due to a specific kernel build, i.e., tool run, is slightly different, although with large overlap of reports to the reports of other stakeholders.
Currently, we use different products for runs with different configs. This leads that a report that is common to two configs is recorded twice in the two products, and the assessment of the report is not shared between the two products.
We could use individual runs for each config within a product, which would make the sharing possible, but that would also mix together with runs of different versions, i.e., we already use runs for the results on the daily version.
Describe the solution you would like
To make tracking of static analysis reports a reasonable community effort, we would like to combine results from multiple configurations to one run and simply tag each report in which configuration this report was included.
Such a tagging, as available for github issues, would allow to implement many more flexible/other use cases as well.
Describe alternatives you have considered
We are happy to consider any other alternative.
Additional context
tbd.