See https://docs.sonarqube.org/display/SONAR/Documentation for current functionality
Parameters to configure project analysis can be set in multiple places. Here is the hierarchy of parameters:
- Global analysis parameters, defined in the UI, apply to all the projects (From the top bar, go to Settings > General Settings)
- Project analysis parameters, defined in the UI, override global parameters (At a project level, go to Configuration > Settings)
- Project analysis parameters, defined in a project analysis configuration file or an analyzer configuration file, override the ones defined in the UI
- Analysis / Command line parameters, defined when launching an analysis, override project analysis parameters
sonar.exclusionsparameter via command line for a specific project, it will not be stored in the database. Local analyses in Eclipse, for example, would still be executed with the exclusions defined in the UI and therefore stored in the DB.
The project key that is unique for each project.
When using Maven, it is automatically set to
Name of the project that will be displayed on the web interface.
The project version.
Comma-separated paths to directories containing source files.
If Anyone does not have permission to perform analyses, you'll need to supply the credentials of a user with Execute Analysis permission for the analysis to run under.
|The login or authentication token of a SonarQube user with Execute Analysis permission.|
|The password that goes with the |
|Maximum time to wait for the response of a Web Service call (in seconds)||60|
The project description.
Comma-separated paths to directories containing tests.
Set the analysis mode. See Concepts.
Set the language of the source code to analyze. Browse the Plugin Library page to get the list of all available languages. If not set, a multi-language analysis will be triggered.
Set the source file encoding.
Encoding of source files. Example of values: UTF-8, MacRoman, Shift_JIS. This property can be replaced by the standard property
The list of available encodings depends on your JVM. See http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html (column : Canonical Name for java.nio API)
Assign a date to the analysis.
Note: This parameter is applicable to a few, special use cases, rather than being an "every day" parameter:
To answer those use cases, you can use the sonar.projectDate property. The format is
The process is the following:
Since you cannot perform an analysis dated prior to the most recent one in the database, you must analyze your versions in chronological order, oldest first.
Note: You may need to adjust your housekeeping settings if you wish to create a long-running history.
Manage SCM branches. Two branches of the same project are considered to be different projects in SonarQube. As a consequence issues found in a project A in a branch B1 are not linked to issues found for this project A in a branch B2. Currently, there is no way to resolve automatically issues of B2 when they are resolved in B1 as again A-B1 & A-B2 are considered as separated project.
If you are a user of Developer Cockpit, please see "Limitation" section in the Developer Cockpit Installation and Usage
Default profile for the given language
Skip the computation of design metrics and dependencies.
Currently only available for Java.
Use this property when you need analysis to take place in a directory other than the one from which it starts. E.G. 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 the source directory, but some parent 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 the new
Note that the analysis process will need write permissions in this directory; it is where the
Set the working directory for an analysis triggered with the SonarQube Runner or the SonarQube Ant Task (versions greater than 2.0).
Path must be relative and unique for each project.
Beware: the specified folder is deleted before each analysis.
|This property can be used to explicitly tell SonarQube which SCM plugin should be used to grab SCM data on the project (in case auto-detection does not work). The value of this property is always lowercase and depends on the plugin (ex. "tfvc" for the TFVC plugin). Check the documentation page of each plugin to know more.|
|By default, blame information is only retrieved for changed files. Set this property to |
Exclusions / Inclusions
See Narrowing the Focus to:
- Exclude files from analysis
- Prevent some files from being checked for duplications
- Prevent some files from being taken into account for code coverage by unit tests and integration tests
- Ignore issues on certain components and against certain coding rules
|If set to true, all files are imported - with respect to inclusions and exclusions, even if there is no matching language plugin installed.|
Control the quantity / level of logs produced during an analysis.
Deprecated since 5.1, replaced by sonar.log.level=TRACE | DEBUG
Display logs to see where the analyzer spends time.
This parameter is generating a file containing these timing infos in
<workingDir>/profiling/<moduleKey>-profiler.xml where <workingDir> is:
Add more detail to both client and server-side analysis logs.
Parameters specific to the "issues" mode
Those parameters are listed here for completeness of this documentation page - but regular users should not have to worry about them because they mainly target integration use cases.
Controls whether an "issues"-mode analysis should query the server every time (to get the project settings, the rule repositories, the project issues, ...) or if it should rely on a local cache to speed up analysis. This local cache is invalidated once per day.
Path to which a JSON file with all the issues found during analysis should be output. This path is relative to the working directory (see "sonar.working.directory"). By default, no file is generated.