Ericsson / codechecker

CodeChecker is an analyzer tooling, defect database and viewer extension for static and dynamic analyzer tools.
https://codechecker.readthedocs.io
Apache License 2.0
2.28k stars 383 forks source link

More flexible tags for reports #3404

Open bulwahn opened 3 years ago

bulwahn commented 3 years ago

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.

csordasmarton commented 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.

bulwahn commented 3 years ago

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.