My company uses SonarQube to analyze code, and the new version 4.3 of the sonar does not show the languages of each project in the dashboard. Could someone tell me the way to fix this problem?
I would greatly appreciate it!
Since SonarQube 4.2, projects are analyzed using a multi-language strategy, so it does not really make sense anymore to display a project's (single) language, since one project can contain several analyzed file types (think e.g Java, XML, HTML, CSS and JavaScript for a Web application with a Java backend).
Note that in the upcoming SonarQube 4.4, the Project Size widget has been revamped to display distribution of lines of code by language.
Related
Sonar scanner runs analysis for all the available plugins installed in SonarQube. But for some of the projects analysis should be run only for some languages(For example Java and Javascript).
sonar.language parameter allows me to set only one language.
Is there any way to set multiple languages for analysis.
Stop thinking in term of language, since this is a blur concept in SonarQube. Just exclude the files you don't want to analyze, using for example the property sonar.exclusions.
For example, when considering a pom.xml file, the "language" was historically XML (and rules provided by SonarXML). But we now also have rules provided by SonarJava.
The property sonar.language was deprecated in SonarQube 4.4 and might be removed in SonarQube 6.7 or later, because SonarQube can now use several languages (which seems to be exactly the issue that you face currently).
If you only want Java and Javascript issues to be reported, I suggest to create custom quality profiles for all other languages, containing 0 rules. You can then, for your project, explicitly assign those "void" quality profiles.
In the old version, there was a dashboard for the whole project from different views, but in the latest version there isn't. Why was this dashboard removed?
The short answer is that rather than making you figure out which measures are most important, and making you figure out how to display them, recent versions of SonarQube handle the hard work for you with a standard, non-customizable project homepage, and the new Projects space.
I have a Go project that I would like to import into SonarQube 5.1, using SonarRunner.
I know it's not one of SonarQube's supported languages so I have set the property
sonar.import_unknown_files=true
to accomplish some basic level of import - and it does the job. The project also has code coverage in Cobertura format, generated using https://github.com/axw/gocov/ and https://github.com/AlekSi/gocov-xml.
I have not been successful in getting this XML to import with settings:
sonar.core.codeCoveragePlugin=cobertura
sonar.cobertura.reportPath=coverage.xml
Hence the project appears as a gray box on the Sonar dashboard. Has anyone done something similar and got it working? Is it because Go is an unsupported language?
Many thanks!
Andy
Since SonarQube 7.9 (July 2019), the go language is officially supported.
That includes code coverage for Go.
And it is supported in the community edition!
40 rules for Go were present since SonarQube 6.7 .
But the legacy SonarSource/sonar-go, the Go Analyzer for SonarQube, is now SonarQube LTS) par of SonarSource/slang (SonarSource Language), which is a framework to quickly develop code analyzers for SonarQube.
See MMF-1670 (Migrate Go to SLANG)
SonarGo is relying on the UAST technology developed early in the ideation phase of an unified language to write language parsers, which later led to the creation of SLANG.
In order to unify the technologies we use, reduce the maintain cost, and benefit from more features, we need to migrate the current SonarGO implementation to a GO plugin relying solely on the SLANG framework.
See its Go code coverage SLang issues, in particular: SONARSLANG-399
sonarqube {
properties {
property 'sonar.sources', '.'
property 'sonar.exclusions', '**/*_test.go,**/generate_source.go,**/*_generated.go,**/build/**,**/.gogradle/**'
property 'sonar.tests', '.'
property 'sonar.test.inclusions', '**/*_test.go'
property 'sonar.test.exclusions', '**/build/**,**/.gogradle/**'
property 'sonar.go.tests.reportPaths', "${project.projectDir}/.gogradle/reports/test-report.out"
property 'sonar.go.coverage.reportPaths', "${project.projectDir}/.gogradle/reports/coverage/profiles/github.com%2FSonarSource%2Fsonar-go%2Fuast-generator-go.out"
}
}
SONARSLANG-408 ("[Go] Import Go Cover report") is still in progress though.
(But is only 4 hours old, at the time of writing)
Yes, to my knowledge the SonarQube Cobertura plugin only allows to import coverage reports for Java (and maybe supported JVM based languages).
However, if you are willing to do some transformation on your coverage result file, the Generic Test Coverage plugin might suit your needs.
We need to uninstall a language plugin from SonarQUBE, and as a first step, we want to purge all project analysis configured with this language (not multi-language ones).
We have seen in project description, the language selected for this project, but is it possible to configure a filter per language and do a bulk deletion somehow?
Many thanks.
Richard
It was possible before SonarQube 4.2, but since the multi-language support has been added in 4.2, this is unfortunately no more possible.
I would like to know if you have a junction between the two profiles of quality, creating a single.
I have a project that uses the JEE technology, and it uses javascript, java and JSF.
Wanted to make a junction of quality profiles (Web + Javascript + Sonar way with Findbugs)
Is there any way to do this?
I'm using sonarqube 4.3 and sonar runner 2.4.
According for your reply
I have to call the sonar runner several times
first for Sonar way in Web perfil
second for Sonar way in JavaScript perfis
third for Sonar way with Findbugs in Java perfis
would give me an example?
You actually don't have to do this and this is not the correct way to solve your problem anyway.
As of SonarQube 4.2 you can use the multilanguage feature and your files will be automatically analyzed by the correct language plugin (detection is based on file extension).
If you are using a version prior to 4.2 you will have to run multiple analysis with the correct language set each time.