558ERROR: File src/Savvyio.Extensions.EFCore.Domain/EfCoreAggregateDataSource.cs can’t be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files
I will enable my verbose logs for my next run - for now the important thing was to verify if this is a breaking change with v8.0.0 - and I can confirm that it is.
There indeed probably is something broken on our side, as v8.0.0 was a pretty big change (hence the major bump).
We have a few more cases like yours in community, and the more info the better to investigate it.
It’s awesome that you shared your repo, I will try to reproduce the behavior locally and get back to you
Even I had the same issue after the new version got updated, when I reverted to the older version of 7.1.1 it started working without any problems, I am using an Ubuntu-based image to Build the pipeline in AWS CI (CodeBuild) Repository (CodeCommit).
My Concern is before 8.0 it was working fine from last two years without any issues, apart from this, there is no configuration change
I have generated the verbose and see it has our library and class details, the organization is not comfortable to sharing it. can you please suggest any alternate way.
Note: We are using Team plan subscription for Sonarcloud
For sure - it has just been high priority to have the ball rolling, why I am currently using last stable version prior to 8.0.0. I will make a PR and play around … and see if I can share the result with you. I hope to do it either later today or early next week.
Sadly, it still fails with the same error (even in 8.0.1). What should I do about the log? I don’t know how to copy the text, as it only copies what is in screen (even I marked all 7.000 lines).
Just to be clear; I will rollback to last stable version again.
If you want to investigate beyond the logs, feel free to fork or clone my repo - its MIT. 204_🔬 Code Quality Analysis.log (4.1 MB)
I finally figured out what happened here, by forking your repo and playing with the scanner version.
On v8.0.0, we introduced multi-language support, as well as changed a bit how the projectBaseDir is calculated.
Basically, the projectBaseDir in your project used to be savvyio/savvyio/src/ in v7.1.0 and now it is savvyio/savvyio/ in v8.0.0.
The problem here is that you are manually setting sonar.sources=src/.
In v7.1.0, this means that your sonar.sources are ignored, as the projectBaseDir, namely savvyio/savvyio/src/, does not contain a directory src/.
On v8.0.0, the projectBaseDir is savvyio/savvyio/, which indeed DOES contain src/.
So in this version we are considering src/ as a viable directory and the end step enumerates the files. This comes in conflict with our own file detection, as we are detecting the files that were part of the compilation and some of them are inside src/.
Can I ask you if you could remove the “defaults” found here, and instead rely on our automatic detection?
We are thinking on how to proceed with sonar.sources and sonar.tests, as we do not properly support them right now.
Last but definitely not least, I want to thank you for making this thread and linking your OSS repo, as it was pivotal in finding the erroneous behavior and making our product better.
All my projects are using /src for source code - and /test for unit-/functional tests.
Will this work if I decide to remove these two properties (sonar.sources/sonar.tests) and use v8+ going forward?
If memory serves me right, this was the only way I could be 100% sure, that SonarCloud would not mix test code with source code. Eventhough all test code has the sonar exclude and other attributes set, sometimes it did not honor this … and the only “peace-of-mind” way to do it, was to use said two properties.
You are absolutely right, the documentation is not aligned with this.
This is a bit of an edge case, as usually .NET analysis does not require sources and tests to be set, as they are automatically populated. For this reason, the behavior was flaky at best and the documentation is not quite right.
With the v8.0.0 release, this became even more apparent, as the projectBaseDir is now set to the working directory.
If you find the time, could you please do a test with removing the sources and tests and let me know if the behavior is different than expected?
I will for sure have it in mind - I have quite a number of FOSS projects, so my concern is it might work for one but not for the others (where this src/test has proven worked every time - except latest SonarCloud MS Build thingy), and it time of writing, I am slightly overwhelmed with tasks at hand.
That written - I will keep you posted when time allows for it.
Keep up the good work; SonarCloud has a positive impact to keep code clean!
We recently released v9.0.
In that version, we are ignoring user-supplied sonar.sources and sonar.tests.
Based on how the scanner for .NET works, there is no reason to use these parameters.
In fact, if you used them before v8.0, it was at best a no-op and at worst a double-index failure.
After v8.0, it resulted almost always to a double index error.
After v9.0, the bug was fixed and the program should no longer crash.
In any case, to simplify your pipeline I would suggest not including these parameters to your begin step.
Cheers, thanks for the report!
It was quite helpful
