Analysis Parameters

Most project analysis settings can be configured in three different places: in the UI, in a configuration file, or on the command line. In most cases, the descriptions of those properties and the best place to set them is in the UI when possible. Only parameters set through the UI are reusable for subsequent analysis and there is a structure to the way parameters are read by the scanner.

Setting configuration in the SonarCloud UI

Many analysis parameters can be configured in the SonarCloud UI itself. These can be found under Your Organization > Your Project > Administration > General Settings

Setting configuration in a file

Analysis parameters can also be set in a configuration file within your project. The file used depends on your setup:

• Maven Java project: pom.xml
• Gradle Java project: build.gradle
• Ant Java project: build.xml
• Other CI-based analysis: sonar-project.properties
• Automatic analysis: .sonarcloud.properties

Setting configuration on the command line

For CI-based analysis (not automatic analysis), parameters can also be set on the command line using the -D option indicator when launching an analysis. This can be done with the standalone command-line tool sonar-scanner, as well as with any of the build-tool-specific variants like SonarScanner for Maven and SonarScanner for Gradle.

Settings stored in database

Only parameters set through the UI are stored in the database. For example, if you override the sonar.exclusions parameter via the command line for a specific project, it will not be stored in the database. Subsequent analyses, or analyses in SonarLint with Connected Mode, would still be executed with the exclusions defined in the UI and therefore stored in the database.

Most of the property keys shown in the UI at both global and project levels can also be set as analysis parameters, but the parameters listed below can only be set at analysis time.

For language-specific parameters related to test coverage and execution, see the documentation on Test Coverage. For language-specific parameters related to external issue reports, see the page about External Analyzer Reports.

Mandatory parameters

Authentication

If the "Anyone" pseudo-group does not have permission to perform analyses, you will need to supply the credentials of a user with "Execute Analysis" permission for the analysis to run under.

• sonar.login
  • The login or authentication token of a SonarCloud user with "Execute Analysis" permission on the project.
• sonar.password
  • The password that goes with the sonar.login username. This should be left blank if an authentication token is being used.

Server

• sonar.host.url
  • The URL of the SonarCloud server. You must define this URL because the SonarScanners also work with SonarQube which uses a different URL.
  • Default: https://sonarcloud.io.

Project configuration

• sonar.projectKey
  • The project's unique key. You can use up to 400 characters. All letters, digits, dash, underscore, periods, and colons are accepted. 
  • Default: For Maven projects, <groupId>:<artifactId>.
• sonar.organization
  • The key of the organization to which the project belongs.

Optional Parameters

Project identity

• sonar.projectName
  • Name of the project that will be displayed on the web interface.
  • Default: For Maven projects, <name>, otherwise, the project key. If not provided and there is already a name in the DB, it will not be overwritten.
• sonar.projectVersion
  • The project version. Do not use your build number as sonar.projectVersion.
  • Default: For Maven projects, <version>, otherwise, "not provided".

Project configuration

• sonar.sources
  • Comma-separated paths to directories containing main source files.
  • Default: For Maven, Gradle, and .NET projects, the value is read from the build system. Otherwise, if neither sonar.sources nor sonar.tests are provided, is read from the project base directory.
• sonar.tests
  • Comma-separated paths to directories containing test source files.
  • Default: For Maven, Gradle, and .NET projects, read from the build system.
• sonar.externalIssuesReportPaths
  • Comma-delimited list of paths to generic issue reports.
  • See the full list on the External Analyzer Reports page.
• sonar.scm.exclusions.disabled
  • For supported engines, files ignored by the SCM, i.e., files listed in .gitignore, will automatically be ignored by analysis too. Set this property to true to disable this feature.
• sonar.scm.revision
  • Overrides the revision, for instance, the Git sha1, displayed in analysis results.
  • Default: Provided by the CI environment or guessed from the checked-out sources.
• sonar.buildString
  • The string passed with this property will be stored with the analysis and available in the results of api/project_analyses/search, thus allowing you to later identify a specific analysis and obtain its ID for use with api/project_analyses/set_baseline.
• sonar.analysis.${yourKey}
  • This property stub allows you to insert custom key/value pairs into the analysis context, which will also be passed forward to webhooks.

Duplications

• sonar.cpd.${language}.minimumtokens
  • For non-Java projects, a piece of code is considered duplicated if sonar.cpd.${language}.minimumtokens identical tokens are found across at least sonar.cpd.${language}.minimumLines lines of code.
  • For Java projects, a piece of code is considered duplicated when there is a series of at least 10 statements in a row, regardless of the number of tokens and lines. This threshold cannot be overridden.
  • Default: 100
• sonar.cpd.${language}.minimumLines
  • Default: 10

Analysis logging

• sonar.log.level
  • Control the quantity/level of logs produced during an analysis. From least to most verbose: INFO, DEBUG or TRACE. DEBUG is similar to sonar.verbose=true. TRACE is DEBUG with added timings of all ElasticSearch queries and Web API calls executed by the SonarScanner.
  • Default: INFO
• sonar.verbose
  • true or false. true adds more detail to both client and server-side analysis logs, activating DEBUG mode for the scanner, and adding client-side environment variables and system properties to the server-side log of analysis report processing.
  • Note: There is the potential for this setting to expose sensitive information such as passwords if they are stored as server-side environment variables.
  • Default: false
• sonar.showProfiling
  • true or false. true displays logs showing where the analyzer spends time. Generates a file containing this timing information in <workingDir>/profiling/<moduleKey>-profiler.xml where <workingDir> is .sonar/profiling/ when analysis is run with SonarScanner, and target/sonar/profiling/ when SonarScanner for Maven is used.
  • Default: false.
• sonar.scanner.dumpToFile
  • Outputs to the specified file the full list of properties passed to the scanner API as a means to debug analysis. The equivalent output is available in Your Project >  Administration > Background Tasks > 3-dots menu > Show SonarScanner Context.
  • Note: If the analysis report fails, the list is not generated and there won't be anything available on the server.
  • Default: Not applicable.
• sonar.scanner.metadataFilePath
  • Sets the location where the scanner writes the report-task.txt file containing among other things the ceTaskId.
  • Default: The value of sonar.working.directory.

Web services

• sonar.ws.timeout
  • Maximum time to wait for the response of a web service call, in seconds. Modifying this value from the default is useful only when you're experiencing timeouts during analysis while waiting for the server to respond to web service calls.
  • Default: 60

Other

• sonar.links.ci
  • The continuous integration system being used.
  • Default: For Maven projects, <ciManagement><URL>.
• sonar.links.homepage
  • The URL of the project home page.
  • Default: For Maven projects, <URL>.
• sonar.links.issue
  • The issue tracker being used.
  • Default: For Maven projects, <issueManagement><url>
• sonar.links.scm
  • The project source code repository.
  • Default: For Maven projects, <scm><URL>.
• sonar.projectBaseDir
  • Use this property when you need the analysis to take place in a directory other than the one from which it was launched. For example, analysis begins from jenkins/jobs/myjob/workspace but the files to be analyzed are in ftpdrop/cobol/project1. The path may be relative or absolute. Specify not the source directory, but some ancestor of the source directory. The value specified here becomes the new "analysis directory", and other paths are then specified as though the analysis were starting from that specified value. Note that the analysis process will need write permissions in this directory; it is where the sonar.working.directory will be created.
  • Default: The directory from which the SonarScanner is launched.
• sonar.sourceEncoding
  • Encoding of the source files. For example, UTF-8, MacRoman, Shift_JIS. In Maven projects, this property can be replaced by the standard property project.build.sourceEncoding. The list of available encodings depends on your JVM.
  • Default: System encoding.
• sonar.scm.forceReloadAll
  • By default, blame information is only retrieved for changed files. Set this property to true to load blame information for all files, which may significantly increase analysis duration. This can be useful if you feel that some SCM data is outdated but SonarCloud does not get the latest information from the SCM engine and this analysis parameter should not be a permanent part of your analysis configuration.
• sonar.working.directory
  • Set the working directory for an analysis triggered with the SonarScanner or the SonarScanner for Ant (versions greater than 2.0). This property is not compatible with the SonarScanner for .NET. The path must be relative, and unique for each project.
  • Warning: the specified folder is deleted before each analysis.
  • Default: .sonar

Deprecated parameters

• sonar.projectDate
  • DEPRECATED - Will be removed in the future. A user warning appears on the project interface if you activate this parameter. 
  • Assign a date to the analysis. This parameter is only useful when you need to retroactively create the history of a project not analyzed previously. The format is yyyy-MM-dd (for example, 2010-12-01). Since you cannot perform an analysis dated prior to the most recent one in the database, you must recreate your project history in chronological order, the oldest first.
  • Default: Current date.