Getting Started

For an out-of-the-box setup, you can use the following docker-compose recipe or a docker image with SonarQube which contains bundled sonar-scala plugin. Please see mwz/sonar-scala-docker for more details or simply follow this guide.

Alternatively, if you already have a SonarQube instance or you don't want to use Docker, you can download the latest release jar into your SonarQube plugins folder /opt/sonarqube/extensions/plugins and restart SonarQube either manually or using the update center.

For automating the analysis of your Scala projects, check out mwz/sbt-sonar sbt plugin and the documentation here. Alternatively, see the examples directory in sonar-scala repository, which includes example projects for SBT (1.x), Gradle (5.x) and Maven (3.x) along with basic instructions on how to execute SonarQube analysis for each of those projects without sbt-sonar.

Quick start

Let's start off by adding the following sbt plugins to your Scala project, in the ./project/plugins.sbt file:

addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.6.1")
addSbtPlugin("com.sonar-scala" % "sbt-sonar" % "2.3.0")

We've added the sbt-scoverage plugin so that we can generate a coverage report and the sbt-sonar plugin to easily trigger an analysis via an sbt task.

Let's start a local SonarQube server for demonstration purposes.

docker run -p 80:9000 \
  mwizner/sonarqube-scala-plugins:latest-full

Once SonarQube starts up, you should see the message saying that SonarQube is up and the UI should be available through http://localhost. The login credentials are admin:admin in case you want to browse around.

Since we haven't specified an external database for SonarQube to use, it runs in a demo mode using an embedded database, which will be lost once the docker container is stopped. Please use an external database in a production environment.

Finally, let's execute a SonarQube scan via sbt.

sbt -Dsonar.host.url=http://localhost \
  clean coverage test coverageReport sonarScan

Once the scan completes successfully, you can navigate to http://localhost/projects to see the results.

This basic setup should report to SonarQube all of the useful Size, Coverage and Test metrics (listed here) in addition to raising any Scalastyle issues that were identified in your project.

Running analysis from a Windows machine is currently not supported - please use Linux or other Unix-like operating system.

Scapegoat

Let's add Scapegoat to our project to get even more useful report.

Add following sbt plugin to your Scala project, in the ./project/plugins.sbt file:

addSbtPlugin("com.sksamuel.scapegoat" % "sbt-scapegoat" % "1.1.0")

Set the latest Scapegoat version and the format of a report generated by Scapegoat in your build.sbt file:

scapegoatVersion in ThisBuild := "1.3.9"
scapegoatReports := Seq("xml")

Also, to make sure your project doesn't fail to compile due to any Scapegoat errors, you can temporarily override the default severity level of all the inspections - all Scapegoat issues will be still reported to SonarQube with the correct severity level according to the configuration in your quality profile.

scalacOptions in Scapegoat += "-P:scapegoat:overrideLevels:all=Warning"

You can now run the scapegoat task using sbt, which should generate a report with all the style issues that Scapegoat identified.

sbt scapegoat

Once you've done that, you will need to run the sonarScan task again to include the Scapegoat report in SonarQube analysis.

Here are all of the sbt tasks put together:

sbt -Dsonar.host.url=http://localhost \
  clean coverage test coverageReport scapegoat sonarScan