We are using SonarCloud for scanning primarily gradle built java projects in our organization, via suggested route of using gradle sonar scanner.
Recently we are trying to enrich sonar reports with generated code, e.g. mapstruct generated code. To enable this we fiddle with the following properties in our build.gradle sonar → properties configuration block:
sonar.sources are enriched to contain the path where generated code resides by setting the following property "sonar.sources", "src/main,build/generated/sources/annotationProcessor/java/main"
we make sure to disable scm exclusions by setting the following property "sonar.scm.exclusions.disabled", "true"
This works well for main/long-lived branches as they pick up a new source folder as can be observed in the following picture:
However for pull requests analysis this doesn’t work as generated sources aren’t picked up, only src source set is present.
build.gradle file, hence sonar properties as well as gradle command used to execute build process and sonar analysis is the same on both pull request and main branch pipelines.
How can we enable generated code to show up in pull request analysis?
Yes, the generated code changes in the PR. To re-emphasize this, generated code is in .gitingore by default as it ends up in the build folder, hence the necessity for the sonar.scm.exclusions.disabled flag. Might it be that new code mechanism doesn’t take into account .gitgnore(d) files?
And I do agree that it’s questionable if the generated code should be scanned. For instance lombok generated code we don’t take into account, but mapstruct is different as it’s far more involved in the application logic than it should be (not a good practice to be honest, but I have seen this on many java projects so far). That said, here is the opinion of the mapstruct project lead on the topic - Add annotations to Generated code · Issue #1574 · mapstruct/mapstruct · GitHub
I do not agree with this because I do not agree that the code generated by MapStruct should not be tested and be unverified. We strive for generating code that looks like it has been written by a person, which means that it shouldn’t have warnings. The generated code usually is simple, but there can be complex things due to the different configuration options we have, you should most definitely test that the mappings that are generated are mapping your data as you would expect.
Wellll… I think this is your problem. Analysis relies on SCM data for new code detection. If you’ve told Git to ignore your generated code, then… Git can’t tell us it’s new.
