Actually I am Analyzing projects .net framework with GitHub Actions.
I have a problem using the sonar-scanner-9.0.0.100868-net-framework client, this in order to analyze a .net framework 4.8 code, the CS lines of code are not analyzed and only duplicate code is displayed:
I checked the logs and from what I can see, although 14 projects are detected, the analyzers do not raise any issues. I would need more details to understand why. Would it be possible to share with us the logs in the verbose mode? You can enable verbose mode by using /d:sonar.verbose=true parameter when calling the scanner begin command.
Would it be possible to share the dotnet build logs in the binary format? You can generate the binary format by providing the -bl: parameter like so: dotnet build --no-incremental -nr:false -bl:build.binlog.
This will give us more insight into why the analyzers are not properly linked and executed during the build.
I’m sorry to get back to you and ask for more logs, but could you please share with us the .sonarqube folder generated after the project has been built?
For the run we have logs, it was generated to D:\a\davi-atm-multiservicios-mngr\davi-atm-multiservicios-mngr\NET\DAV_MULTIVENDOR\.sonarqube.
When checking the logs everything looks fine: the projects are categorized as MAIN code categorized as MAIN project (production code), the files are found for analysis Number of files to analyse: 70. and the analyzers are passed to the compiler /analyzer:...\SonarAnalyzer.CSharp.dll. At the same time, there are no sonar warnings raised and there are no lines of code reported, which means that the analyzers were not executed.
I was caught up with other tasks, and only now I found some time to take a look. From what I can see, the analyzer that is responsible for computing metrics was executed, but it generated data only for just a few files (like SharedAssemblyInfo.cs).
One reason this might happen is if the analyzer detects that the code is generated. Are any of the following attributes used in the code files?
DebuggerNonUserCode
DebuggerNonUserCodeAttribute
GeneratedCode
GeneratedCodeAttribute
CompilerGenerated
CompilerGeneratedAttribute
Or, do the files (maybe the headers) contain comments with the following strings:
“auto-generated”
“autogenerated”
“generated by”?
Any of these criteria might make the analyzer think that it’s analyzing generated code, which would lead to skipping the analysis.
One thing you might try (just for a test) is to enable generated code analysis
I took a look at your problem as well and discussed it a bit with my colleague.
The reason this behavior is happening is because we are considering your analysis as an Incremental PR analysis.
This means that we are not analyzing all the files, but only the ones that have changed between the PR branch and the base branch. This happens for performance, so that the scan is faster, as a full-scan has to look into more finals and generate issues and metadata.
We noticed that it is not currently possible to disable this, so I made a ticket where you can track the effort.
What I am curious about is why you can see the files in the screenshot at all.
If the analysis is working as intended, then the files should not appear at the browser.
I have a couple of follow up questions for you:
Are the logs you send us happening in a PR? Or do they happen on a branch everytime someone merges, like for example master or a long-lived branch? From the logs, I think it is a PR, as GitHub Actions seem to be setting GITHUB_BASE_REF, which is a PR-exclusive environment variable.
Furthermore, could I please see your workflow YML file? If you are not comfortable with sharing the entire thing, I mostly care about the events part. For example:
on:
push:
branches:
- master
pull_request:
branches:
- master
From where did you take the screenshot above? Can you send me the URL? Even if I cannot access it, I want to see which view you are looking at. And a bigger screenshot of the view would be appreciated, where I can see the header, like so:
Sorry for the delay in the response:
Are the logs you send us happening in a PR? R/ Yes, these logs come from a PR, this pull request start YML secuence:
It’s funny you say that, because I went back to the first set of logs you shared and noticed that your scanner command explicitly sets sonar.branch.name.
The analysis is triggered on a PR event, so the scanner attempts to use the analysis cache
This excludes many of your files from analysis because the cache is being used
The scanner is forced to use sonar.branch.name=integration, resulting in a branch analysis (rather than a PR analysis)
The analysis is submitted to SonarQube Cloud as a branch analysis using the PR cache, which results in the behavior you’re seeing.
The answer here is probably as simple as removing sonar.branch.name from your scanner command and letting the scanner auto-detect whether it should be analyzed as a PR or as a branch.
If you really want to preserve a branch analysis of the integration branch (to see the full results, not just what changed in a PR) , you could add integration to the branches you list under on: push: branches: of your GitHub Actions YML.