Could the double indexing error message be enriched with some information to help debugging it?

SonarQube
,
1

Dear community,

Would it be possible to enrich the double indexing error message with some more information?
(“main and test files” sounds like a default, not actual indexing categories)

An example instance: “CMakeLists.txt can’t be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files”

In this case Sonar obviously knows that the file was already indexed, and most probably also checked that it would not receive the same index.
As such, instead of the above error message, I believe it would be better if sonar could include how the files was categorized previously and how it would be categorized right now.
This could help in debugging where and what I might have done incorrectly.

Also … when looking up previous logs I can find one that lists it as “indexed with no language”.
If it was not categorized to any supported language, why does sonar assume it is a main or test file?
Could the current duplication checking algorithm be changed so that if a file was previously indexed, but not as belonging to any supported language and later it would be indexed differently, it receives the last index (maybe also with a debug log so that this does not go unreported)?

Thank you in advance,
Kristof

5

Hi Kristof,

Each file in the project (identified by its project relative path) can only be included in a single module, as either a “main” or test file.
With debug logs enabled, you should be able to see in what context the file in question was indexed the first time (in what module, and whether it was indexed as main or test).

Note that the indexing of each file is a result of the combination of several properties and there can also be additional constraints defined by plugins, so it’s not possible for the scanner to figure out why a file got indexed twice.

The fact that no language was detected for file shouldn’t be a condition for the scanner to not validate the correctness of the configuration of the project. The classification of languages is also quite volatile and can be changed, for example, by assigning different file extensions to a language on the server side, and that shouldn’t change the validation of the configuration, possibly resulting in the scanner to suddenly fail.