It seems that over half of the time I try to execute analysis using Sonar Runner 2.4 on several different projects that the analysis completes successfully but the publish (via the background task) to SonarQube fails. There is no log that I can find with relevant information on the SonarQube server for the failed tasks - at least I can't find any. I am new to SonarQube. The SonarQube 5.2 server is on Windows Server 2012 R2 using SQL Server 2012(SP1) database.
The answer is the solution stated in the related SonarQube 5.3 Background Task Fails with No Log in Dashboard . There were several SonarQube servers, which I was unaware of when I originally posted, accessing the same database. When those other instances were shut down there were no more failures in the background tasks.
Related
I have configured IntelliJ with SonarLint to a connected SonarQube instance in AWS. I am able to run a code analysis in IntelliJ and I do get results back in IntelliJ.
But I want to have these results in Sonarqube. How to do this?
You should have a look on the documentation to see how to :
Install SonarQube : https://docs.sonarqube.org/display/SONAR/Installing+the+Server
Execute an analysis : https://docs.sonarqube.org/display/SCAN
If you have Jenkins you should have 2 jobs: one to build application from branch, another to run SonarQube analysis based on artifacts created by first job (build job). You can create a pipeline: when you push to git (or other repository) first job automatically will be started, when build is done and it’s successful it will trigger job to analyze code in sonar. Try to find configuration examples at https://docs.sonar.org/ or I can send you tomorrow details how we configured our pipeline. P.S. forgot to mention that you need to install SonarQube plugin in Jenkins too.
SonarLint: this tool only open connection to your Sonar server just to get rules for analysis, but analysis is done on your side (localhost) without sending results to Sonar server back. This is how SonarLint works.
Sonar scanner version:3.0.1.733
Sonarqube version: 5.6.5
We have a sonar scanner on a Windows box which scans our project and submit a result to our Sonar server which is now on a Linux box. Prior to this, both the scanner and the sonar server and sonar db were on the same Windows box and we did not have any issues. We took a sonar db backup and restored it on another database on our new Linux box (now Sonar DB and Sonarqube server are on our Linux box). The server was installed from the native packages
My Issue now is when our scanner submits to the server no issue get reported. We used to have some issues before and now everything is reset back to zero.
I investigated a little bit, I can see the background tasks were received and processed successfully. Even the server UI shows the date of the latest scan.
The scanner reports success as well. I ran the scanner in the debug mode and I can see connections to the server with 200 status responses.
I cannot see anything out of ordinary in the logs.
If I re-point the scanner back to my old Windows sonar box it still shows correct number of issues.
Could anyone help me on this?
Usual suspect
Inconsistent measures and/or issue counts just after a SonarQube migration/upgrade can indicate that the local ElasticSearch index has been corrupted.
(reminder: ElasticSearch is a search engine used by SonarQube to index issues, rules etc. so that it can access this data rapidly without having to query the database all the time, see SonarQube Architecture).
Solution
stop SonarQube
erase sonar_install_dir/data/es
start SonarQube (note: restart
might take longer due to reindexing)
Root-cause analysis
To the question of why did that happen in the first place: a common case is an ElasticSearch index not being properly rebuilt after upgrading and/or changing database. Here's a typical scenario: you first start SonarQube on embedded H2 database, experiment a bit with it, then plug it to a full-fledged database. If the ElasticSearch index does not get scratched/rebuilt in between, then the index gets corrupted as the database/dataset it used to be in synch with just changed all of the sudden.
Good news
An improvement is coming in SonarQube v6.6 to better detect/handle this scenario at the application level (i.e. detect that ElasticSearch index should be rebuilt because the DB changed). See SONAR-5681 - When a change occurs on the DB, the Elasticsearch index must be dropped .
I have a question that, how analysis happen in sonarqube. when I do mvn sonar:sonar -Dsonar.host.url=http://sonar.com what will happen in background. what I felt is like
Maven will use some plugins and communicate with sonarqube server
Load all the rules that it have in sonarqube server in location we run mvn sonar:sonar
Analyze source code using set of rules we loaded from sonarqube server
push it back to SonarQube database and results will be displayed on SonarQube server
Is this is the proper way that it works? or source code will go into sonarqube server and analysis will happen in sonarqube server itself?
Thanks for the help
You've got it mostly right:
Maven will use some plugins and communicate with SonarQube server
Load all the rules that it have in SonarQube server in location we run mvn sonar:sonar
Analyze source code using set of rules we loaded from SonarQube server
Calculate file-level metrics
Read coverage reports if any
Compile data into an analysis report and push it back to the SonarQube server
The server pops the uploaded report from the queue, and integrates it, storing issues and calculating high-level metrics
User sees updated project status on Project homepage
I am developing a plugin for SonarQube 6.3.1 which execute an analysis and then generate a docx report.
The problem is that I have to wait between these both actions that SonarQube finishes its REPORT task. My plugin is destined to lambda users so without Administrator permissions: so I can not use activityStatus service.
Is there an other way to know if the reporting of a project in SonarQube is terminated? (inside a plugin)
Your analysis take place on the server side ? I think you should run it on a client side, not server side.
Write a plugin with #BatchSide and implements org.sonar.api.batch.postjob.PostJob.
Then your method will execute soon analysis is finish (as you requested)
See https://github.com/SonarSource/sonar-custom-plugin-example/blob/master/src/main/java/org/sonarsource/plugins/example/hooks/DisplayIssuesInScanner.java
And by the way with PostJobContext object you have all infos you need to fill a custom report
In the similar question Sonar-Runner talks to the local database "David RACODON - SonarSource" wrote:
The SonarQube Runner needs to talk to both the database and the web server.
I'm will try to understand why Sonar Runner talks do sonar database, because somebody who use sonar runner will known database user and password and do anything on it, for example change admin password and take control on Sonar instance.
On the other hand, at sonar runner docs (http://docs.sonarqube.org/display/SONAR/Installing+and+Configuring+SonarQube+Runner) I see info:
The SonarQube Runner is recommended as the default launcher to analyze a project with SonarQube.
So, it means that I should give database password to each developer of my team? This is inconsistent. Could somebody explain it?
SonarQube needs to talk to the database in order to save the results (metrics) of the analysis.
I will not talk about all the different possibilities that you can implement in order to avoid SonarQube's users to know the admin login, but here is the one I use:
SonarQube + Runner
Jenkins with Sonar plugin
This post (on my blog) is 1 year old http://qualilogy.com/en/install-sonarqube-the-sonarqub-jenkins-plugin/) but it will give you an idea.
You already have SonarQube + Runner installed.
Install Jenkins
Install SonarQube plugin for Jenkins
Configure the plugin:
Location of Runner
SonarQube dashboard URL
Connection to the DB : password is encrypted.
Then, when configuring and running an analysis from Jenkins, no need to use any DB login as a parameter.
Hope it helps.
As of version 5.2, this is no longer the case. Now, all DB credentials/connections are managed by Sonar itself, not the runner.