|The project description.|
<description> for Maven projects
|Project home page.|
<url> for Maven projects
<ciManagement><url> for Maven projects
<issueManagement><url> for Maven projects
|Project source repository.|
<scm><url> for Maven projects
|Comma-separated paths to directories containing main source files.||Read from build system for Maven, Gradle, MSBuild projects. Defaults to project base directory when neither |
sonar.tests is provided.
|Comma-separated paths to directories containing test source files.||Read from build system for Maven, Gradle, MSBuild projects. Else default to empty.|
|Encoding of the source files. Ex: |
Shift_JIS. This property can be replaced by the standard property
project.build.sourceEncoding in Maven projects. The list of available encodings depends on your JVM.
|Comma-delimited list of paths to Generic Issue reports.|
|Assign a date to the analysis. This parameter is only useful when you need to retroactively create the history of a not-analyzed-before project. 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 analyze recreate your project history in chronological order, oldest first. Note: You may need to adjust your housekeeping settings if you wish to create a long-running history.
|Use this property when you need analysis to take place in a directory other than the one from which it was launched. 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 specified value of
sonar.projectBaseDir. Note that the analysis process will need write permissions in this directory; it is where the
sonar.working.directory will be created.
|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 MSBuild. 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 you're using on the project (in case auto-detection doesn't work). The value of this property is always lowercase and depends on the SCM (ex. "git" if you're using Git). Check the SCM integration documentation for more.|
|By default, blame information is only retrieved for changed files. Set this property to |
true to load blame information for all files. This can be useful is you feel that some SCM data is outdated but SonarQube does not get the latest information from the SCM engine.
|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 that feature. SCM exclusions are always disabled if
sonar.scm.disabled is set to
|Overrides the revision, for instance the Git sha1, displayed in analysis results. By default value is provided by the CI environment or guessed by the checked-out sources.|
|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
|This property stub allows you to insert custom key/value pairs into the analysis context, which will also be passed forward to webhooks.|
|Sets the New Code definition to |
Reference Branch for this analysis, overriding the configuration on the server. The
New Code will be calculated based on the differences between the branch under analysis and the provided branch. This parameter is intended to be set in a configuration file (ex:
sonar-project.properties), specific to a given branch.