I want to use the generic test execution functionality to upload test results for the D Programming Language (file extension .d). Unfortunately there is a validation that only known languages can be used:
throws this error:
Caused by: Line 2 of report refers to a file with an unknown language: source/pei/client/tests/configmanager.d
This seems strange, as the generic test execution reporter should be opened for all languages.
The external issue reporter does not have this restriction and works fine with .d files.
As you have mentioned in another thread (closed now as duplicate), there is the same issue with GenericTestCoverage as well (and the answer / solution is likely to be the same). I haven’t forgotten about this, I’ll get back to you later.
Although both functions suffers from the same problem, they are two unrelated functions located at two different source files. As the other issue is closed as duplicate, only this issue will be solved and the other issue likely will be forgotten. @ganncamp
Please reopen the other issue, thanks.
@andre.pany We don’t forget At a glance I have a feeling we will fix both of these issues at the same time. I’ll update this thread when I get a chance to take a closer look. Until then, let’s just keep this one thread.
@janos
I think maybe there are 2 different solutions for this problem:
Allow test execution and test coverage for unknown languages similar how it is today already possible for generic issue data
Allow lightweight adding of new languages to SonarQube. Just 2 information are necessary. The language name e.g. “D” and the file extensions for the source code files e.g. “*.d, *.di”.
@eraytufan there is unfortunately no answer from SQ.
I created a new issue to get some attention. This new issue although contains a workaround: You have to create a small script which copies your original files to files with extension “.py”. The script copies the content of your original code files into these new files in a way, that it looks like valid python coding but still you see your original coding.
Last thing, the script has to convert your coverage /xunit / scanner reports in a format Python accepts.
@andre.pany
I also found a workaround for generic issue data, however it may not work depending on which language plugin you use or which language is the test case is written. In the Sonar-project.properties file, I defined my test path and source path. After that I added something similar to this line:
sonar.python.file.suffixes=.json
It seems like it solved my problem. It might be because I used a .json file and I haven’t tested it with a different type of file. I don’t know why Sonarqube is trying to parse a test file which can be any type.