CODEWITHSUNDEEP
sonarqubesonarqube-scan
Vahid
Vahid

Reputation: 1957

Sonarqube fails to show the submitted sonar scanner result

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?

Upvotes: 1

Views: 3783

Answers (1)

Nicolas B.
Nicolas B.

Reputation: 7331

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 .

Upvotes: 4

Related Questions