I’m learning how to integrate SonarCloud with Github Actions in a personal project. The Github repository that I am using can be accessed by clicking here.
The solution I am developing was created with version 8.0 of .NET. By default, all source code is present in the src directory. All test projects (unit, integration and functional) are present in the tests directory.
My Github Actions workflow that is integrating with SonarCloud is called Develop Workflow, and can be accessed by clicking here.
As my test and source code directories are separate, I followed the recommendations from the official SonarCloud documentation, and indicated their respective locations in the dotnet-sonarscanner begin command.
However, during the execution of the pipeline (the last execution I performed can be found by clicking here), for some reason the scanner is pointing out the indexing error shared right after.
ERROR: File src/Postech.PhaseOne.GroupEight.TechChallenge.Api/Setup/RepositorySetup.cs can’t be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files
I’m confused by the error since the RepositorySetup file is only being referenced in a single project in my solution.
I would like to ask for help to resolve the problem in question. I tried several alternatives, but the error persists regardless of what I do.
When using the Scanner for .NET, there’s never a need to set these parameters because all the information can be collected from the project/solution files. Try removing them!
The pipeline completed the scan without errors this time, but when I access my SonarCloud dashboard, not a single line of source code has been extracted from the solution.
I am also experiencing same error. Though i dont have duplicate files, i see see the errors (for example: File Responses/UserDetail.cs can’t be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files)
This is same error for both Angular App and dotNET app pipelines.
@Brenojgomes and @Ramesh_Babu, can you create new threads with details about versions, logs, scanner commands, analysis parameters, etc.? This message can be triggered a lot of different, unrelated ways.
@lucasdirani It looks like you’re analyzing a short-lived branch / pull request, which will only raise issues on changed lines of the branch/PR. If all you’re doing is editing Pipeline files, you won’t see any changes on your source code.
Once merged into your main branch, I’d expect that you see full results. You can also delete the branch and adjust your long-lived branch pattern. Upon reanalyzing the branch as a new branch, you’ll see full results (changed lines or not).
Thank you very much, Colin.
The solution really was to transform my branch into long-lived. This way, code coverage was computed correctly, as well as the other metrics.