SonarQube PR analysis raising thousands of issues on existing projects

Tom_Pester · October 31, 2024, 9:32am

Another more pressing issue at this moment that prevents us from enabling SonarQube again on our most used projects by doing the manual intervention, is that we get all issues (7.5 thousand) posted on our pull request instead of the newly introduced ones, even though we did the required manual steps for these projects as by giving the correct configuration in the screenshot below

Isn’t configuring the above parameters the only expected change to get things working again?
This is not the case for us. We do take a shallow git checkout which was fine in our previous SonarQube version (9) where it worked as expected. Now with the upgrade we should also change the way we checkout? I’ll be working on this issue today.

Tom_Pester · October 31, 2024, 10:18am

We are zooming in on the secondary issue of the unexpected full analysis.
Why is this suddenly happening? Is it because we upgrade SonarQube server or the AzureDevops Task? Digging deeper but if you have an efficient solution please say so as we have 70 projects to cover eventually. Thank you.

Because of the full analysis I believe we are also now getting

I’m pretty 99% sure that SonarQube has the main branch analysed as I can see it in the Web UI, however

After some url hacking on my part it seems this link return the cache for main
https://sonarqube.slgnt.io/api/analysis_cache/get?project=selligent.smc.portal.backend&branch=main

Bu this, what the code produces, does not
https://sonarqube.slgnt.io/api/analysis_cache/get?project=selligent.smc.portal.backend&branch=refs%2Fheads%2Fmain

refs/heads is the culprit?

This is our current config

  - task: SonarQubePrepare@7
    displayName: 'SQ Prepare'
    inputs:
      SonarQube: 'SonarQube (k8s)'
      projectKey: 'selligent.smc.portal.backend'
      projectName: 'selligent.smc.portal.backend'
      extraProperties: |
        sonar.exclusions=**/AssemblyInfo.cs,**/TFSBuild/**,**/*.Designer.cs,**/*.resx,**/*.resx.cs,**/*.js,**/*.html,**/*.css,**/*.less,**/*.eslintrc
        sonar.msbuild.testProjectPattern=.*Tests?.*\.(cs|vb)proj$
        sonar.dotnet.excludeTestProjects=true
        sonar.pullrequest.branch=$(SonarQube.PullRequest.Branch)
        sonar.pullrequest.key=$(SonarQube.PullRequest.Key)
        sonar.pullrequest.base=$(SonarQube.PullRequest.Base)
        sonar.pullrequest.provider=$(SonarQube.PullRequest.Provider)

Colin · November 1, 2024, 6:38pm

Hey @Tom_Pester

As I mentioned in the other thread, this issue is unrelated to some changes in SonarQube v10.x around PR Decoration.

I would not have zoomed in on the analysis cache issue at first, so kudos for that. I am surprised to see refs/heads/main in the cache API query.

At this point, I’m pretty sure this issue is related to the Azure DevOps Task. Which task version were you using before?

You can configure sonar.scanner.scanAll to stop analyzing other languages (SonarScanner for .NET 8, now with other languages auto-detection)
You can also try flipping back to some older versions of the tasks (like @v6) to see if it addresses the cache issue. I am going to flag this for attention, as it seems like something is not working as expected with detecting the branch name.

Tom_Pester · November 4, 2024, 4:29pm

Been busy the whole day on this and got it to work by downgrading to V6 of the DevOps task that use scannermode=cli. I’ll report tomorrow as my work day is ending now.
We would like to say goodbye to the V6 asap.

This is the the task that stops working if we change @6 to @7

  - task: SonarQubePrepare@6
    displayName: 'SQ Prepare'
    inputs:
      SonarQube: 'SonarQube (k8s)'
      scannerMode: 'CLI'
      extraProperties: |
        sonar.projectBaseDir=Source\$(ProjectPath)
        sonar.projectKey=selligent.smc.portal.frontend.albatross
        sonar.projectName=selligent.smc.portal.frontend.albatross
        sonar.exclusions=**/*.cs,SelligentWebComponents/**,App/js/ckeditor/**,App/libs/**,App/translations/**,App/build/**,Content/**,**/webpack.config.js,**/importmap-webpack.config.js,App/js/single-spa/**,App/js/**/mf-*.js,Tests/**,**/*.less,**/set-public-path.js
        sonar.sourceEncoding=UTF-8
        sonar.pullrequest.branch=$(SonarQube.PullRequest.Branch)
        sonar.pullrequest.key=$(SonarQube.PullRequest.Key)
        sonar.pullrequest.base=$(SonarQube.PullRequest.Base)
        sonar.pullrequest.provider=$(SonarQube.PullRequest.Provider)
        sonar.ws.timeout=300
        sonar.qualitygate.timeout=1500

Maybe some of the extraProperties need to be changed/migrated.

=> Can I ask, where on earth, that it is documented on how to move from @5 to @6 to @7 of this task? I searched high and low and couldn’t find out.

I know that this taks autodetects the branch information so in essence you should not set the sonar.pullrequest.* anyomore right? But removing that also doesn’t work if the task is in @7

Tom_Pester · November 5, 2024, 9:14am

To come back to your questions

Which task version were you using before?

After we upgraded to SQV10, coming from SQV9, the DevOps task we tried were

@5 does not work with SQV9
=> @6 We noticed somewhat later that the PR annoations are broken
=> @7 Version 7 does not fix this and we disover by clicking around in SQ that we now have to configure repo and project in SQ itslef and not at the client/Azure DevOps anymore
We configure SQ Server and the scannermode=dotnet are working with the prereq (I think, I can do some tests) that we now cannot do a sparse checkout anymore
=> @6 For the scannermode=CLI (we used uppercase since the working beginning) we need to downgrade from @7 to  @6

You can configure sonar.scanner.scanAll to stop analyzing other languages (SonarScanner for .NET 8, now with other languages auto-detection)

It generates a warning message if you are not explicit. I would say the more analysis the better as we are not getting into trouble with our LOC.
Are you saying this warning message can be removed with SonarScanner for .NET 8 as this sonar.scanner.scanAll does not add any benifit?
Also, this is not related to the breaking upgrade from @6 to @7 right? It’s just a tip that you give I presume.

You can also try flipping back to some older versions of the tasks (like @v6) to see if it addresses the cache issue.
I am going to flag this for attention, as it seems like something is not working as expected with detecting the branch name.
Yes, that is what we did, @7 => @6. This did fix the problem so either there is a bug in @7
or we have to do a migration of the tasks settings. But where is the documentation then and what do we have to do?
Our SonarQube server is v10.6

So our remaining task that I would like to address with you is to get the snippet in the above post

task: SonarQubePrepare@6 => 7

Thank you

Colin · November 5, 2024, 8:14pm

Hey @Tom_Pester

I appreciate your follow-up. The point on using the right branch name to pull the cache is still flagged for attention by the Dev Teams. To me, this seems like a bug, not something to fix via changing configuration. They’ll be along soon.

costin.zaharia · November 19, 2024, 2:15pm

Hi,

As far as I can tell, the caching part is a red herring.

Indeed, we use the cache in the incremental analysis context to compare the files analyzed on the master branch with the ones from the PR and analyze only the changed ones. At the same time, even if this does not work and we analyze the full code base, the server always filters out the issues for unchanged files. So, doing a full analysis should not result in linking all the issues to the PR. In the incremental analysis context, the difference between full or partial analysis purely concerns performance (analysis time).

As far as I can tell, there might be multiple problems:

Misconfiguration: Something seems to confuse the server, making it think that the analysis was not done for a PR but for a main branch instead.
- Are you doing a PR analysis or a main branch analysis? Are the pull request parameters correct? It seems that you are using Azure DevOps where we automatically detect the PR parameters. See for example our configuration where we don’t provide them. Is there any reason to manually set them?
The second problem I see is that you hit the maximum number of lines of code. This is most probably caused by a multi-language analysis feature that accounts for all the code in the working directory and indexes all of it.
- I suggest running the tool in verbose mode by setting the sonar.verbose=true property in the extraProperties: list of the SonarQubePrepare. This will make the SonarQubeAnalyze task print all the files indexed for analysis (be aware that this is before filtering so the exclusions are not processed at this point). You can find the file lists in groups prefixed by sonar.sources= and sonar.tests=. By looking at the list you might decide to set some exclusion patterns to remove the files that are not relevant for the analysis. If you decide that you only want to analyze C# code, then setting sonar.scanner.scanAll to false will disable the feature completely.