각 프로젝트가 고유하게 가지고 있는 key 값으로 다음의 문자열을 사용할 수 있습니다:

• 숫자, 문자, '-' , '_' 및 '.'. 1자리 이상의 숫자가 포함되어야 합니다.

Maven을 사용하는 경우 key값은 자동으로 다음으로 설정됩니다: <groupId>:<artifactId>

콤마(',')로 구분된 디렉토리 명칭을 입력할 수 있습니다.

Maven과 호환되나 그렇지 않은 경우 소스코드는 기본 Maven 코드 저장 위치에서 추출합니다.

Name of the project that will be displayed on the web interface.
Set through <name> when using Maven.

• If there is no name defined yet, use the project key
• If there is already a name in the DB, don't overwrite;

The project version.
Set through <version> when using Maven.

The project description.
Not compatible with Maven, which uses the <description> attribute.

sonar.links.ci

Comma-separated paths to directories containing tests.
Not compatible with Maven, which retrieves test from the default location for Java Maven projects.  

sonar.language

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.

sonar.sourceEncoding

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 project.build.sourceEncoding in Maven projects.

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)

System encoding

sonar.projectDate

Assign a date to the analysis.

Note: This parameter is applicable to a few, special use cases, rather than being an "every day" parameter:

• When analyzing a new project, you may want to retroactively create some history for the project in order to get some information on quality trends over the last few versions.
• When moving from one database engine to another, it is highly recommended (even mandatory) to start from a fresh new database schema. In doing so, you will lose the entire history for all your projects. Which is why you may want to feed the new SonarQube database with some historical data.

To answer those use cases, you can use the sonar.projectDate property. The format is yyyy-MM-dd, for example: 2010-12-01.

The process is the following:

• Retrieve a the oldest version of your application's source that you wish to populate into the history (from a specific tag, whatever).
• Run a SonarQube analysis on this project by setting the sonar.projectDate property. Example: sonar-scanner -Dsonar.projectDate=2010-12-01

• Retrieve the next version of the source code of your application, update the sonar.projectDate property, and run another analysis. And so on for all the versions of your application you're interested in.

Note:

Current date

 sonar.branch

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

sonar.profile

Default profile for the given language

sonar.projectBaseDir

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 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 SonarQube Scanner 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.

sonar.scm.provider

sonar.import_unknown_files

false

sonar.log.level

Control the quantity / level of logs produced during an analysis.

DEBUG: 
Display INFO logs + more details at DEBUG level.
Similar to sonar.verbose=true

TRACE: 
Display DEBUG logs + the timings of all ElasticSearch queries and Web API calls executed by the SonarQube Scanner.

INFO

Add more detail to both client and server-side analysis logs.

• Activates DEBUG mode for the scanner. This is a shortcut of sonar.log.level=DEBUG.
• Adds client-side environment variables and system properties to 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.

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:

• .sonar/profiling/ when analysis is run with Sonar Scanner

• target/sonar/profiling/ when Maven is used 

This parameter is set to preview as part of PR analysis.