Best practice to scan a build whose files depend on a config


(dexter) #1

Hello all,

We have a project that compiles for multiple platforms. Depending on the platform, we may scan some files but not others.

We have a Developer edition and we have a Jenkins job that scans the project as soon as a review is submitted to Gerrit (via the Gerrit trigger plugin) to scan the short lived branch.

The problem is that we cannot know in which configuration we have to build since we cannot match modified files to build configurations. We cannot neither build in all configurations since the new scan will overwrite the previous one …

Is there a recommended way to scan such kind of builds whose compiled files depend on the build config ?

Thanks a lot


(Loïc Joly) #2

It looks to me that you could build in all configuration, as long as you analyzer to different projects (MyProject-Linux, MyProject-xbox,…). Am I missing something?


(G Ann Campbell) #3

Hi,

Just to augment what Loic said, we do exactly that (analyze to multiple, per-build-config projects) internally for the SonarCFamily build wrapper.

 
Ann


(dexter) #4

Thank you for these answers.
If we scan to a project per build config, what about the project’s number of issues ? I mean that if a bug is spotted in a file that is common to two configurations, will it appear in both projects, will it be counted twice ?

Instead of creating one project per config, can I push to a short lived branch per config (say for example my_dev-linux and my_dev-xbox) ?


(G Ann Campbell) #5

Hi,

I’d go for long-lived branches instead of short.

 
Ann


(dexter) #6

Hi,

Maybe I did not express it well. Can I perform the scan in two short lived branches that are to be merged into the same long lived branch ? Will the “bug counters” be OK (no duplicates) ?

Thanks


(G Ann Campbell) #7

Hi,

Short-lived branches are designed to be just that: short-lived. Meaning that we’ve made no provision for … releases, a shifting leak period, … lots of other stuff that will be important in the end but that doesn’t leap to mind.

So if you go that route, you’ll be in uncharted territory

And at the same time, if you introduce a new issue in common code, it will show up in both places.

I understand the pain of triaging the issues in both places, but your focus seems to be on the raw counts. Would you explain why that’s such an issue for you?

 
Ann


(dexter) #8

Hello,

I’m a developer and that’s not an issue for me but rather an issue for the Project Manager who needs to tell the customer that he is “compliant” to the requested profile. So more bugs means “we can’t put your code in our cars” …


(G Ann Campbell) #9

Hi,

Thanks for the explanation.

The long and short of it is that if you analyze both configurations, you’re going to get some duplicated issues. If you need to keep that clean for reporting purposes, then you’re going to have to make an effort to reconcile them and close one of each duplicate pair and then maintain that on an ongoing basis.

And you’re best off doing this in either separate projects, which could be aggregated via an Application (Enterprise Edition) so that you have a unified Quality Gate that encompasses all your configurations, or via LLBs.

 
Ann