Project analysis settings can be configured in multiple places. Here is the hierarchy:
-<!-- sonarqube -->
* Global properties, defined in the UI, apply to all projects (From the top bar, go to **[Administration > Configuration > General Settings](/#sonarqube-admin#/admin/settings)**)
-<!-- /sonarqube -->
* Project properties, defined in the UI, override global property values (At a project level, go to **Project Settings > General Settings**)
-* Project analysis parameters, defined in a project analysis configuration file or an analyzer configuration file, override the ones defined in the UI
+* Project analysis parameters, defined in a project analysis configuration file or scanner configuration file, override the ones defined in the UI
* Analysis / Command line parameters, defined when launching an analysis (with `-D` on the command line), override project analysis parameters
Note that only parameters set through the UI are stored in the database.
This page lists analysis parameters related to test coverage and execution reports. For more other parameters, see [Analysis Parameters](/analysis/analysis-parameters/).
-SonarSource analyzers do not run your tests or generate reports. They only import pre-generated reports. Below you'll find language- and tool-specific analysis parameters for importing coverage and execution reports.
+SonarQube doesn't run your tests or generate reports. It only imports pre-generated reports. Below you'll find language- and tool-specific analysis parameters for importing coverage and execution reports.
In the [Guides](https://community.sonarsource.com/c/announce/guides) category of the [SonarSource Community forum](https://community.sonarsource.com/) you might find instructions on generating these reports.
`*`|any number of characters
`**`|any number of directories
-
-
## Test Coverage
Unless otherwise specified, these properties require values that are relative to project root.
This page lists analysis parameters related to the import of issues raised by external, third-party analyzers. If your analyzer isn't on this page, see the [Generic Issue Import Format](/analysis/generic-issue/) for a generic way to import external issues.
-SonarSource analyzers do not run your external analyzers or generate reports. They only import pre-generated reports. Below you'll find language- and tool-specific analysis parameters for importing reports generated by external analyzers.
+SonarQube doesn't run your external analyzers or generate reports. It only imports pre-generated reports. Below you'll find language- and tool-specific analysis parameters for importing reports generated by external analyzers.
In the [Guides](https://community.sonarsource.com/c/announce/guides) category of the [SonarSource Community forum](https://community.sonarsource.com/) you might find instructions on generating these reports.
url: /analysis/generic-test/
---
-Out of the box, {instance} supports generic formats for test coverage and test execution import. If your coverage engines' native output formats aren't supported by your language plugins, simply covert them to these formats.
+Out of the box, SonarQube supports generic formats for test coverage and test execution import. If your coverage engines' native output formats aren't supported by SonarQube, simply covert them to these formats:
## Generic Coverage
Report paths should be passed in a comma-delimited list to:
url: /analysis/languages/overview/
---
-SonarQube allows to analyze different languages depending on the Edition you are running.
+SonarQube provides analysis of different languages depending on the edition you're running.
| Language | Community Edition | Developer Edition | Enterprise Edition and Data Center Edtion |
| ------------------------------------ | ---------------------- | ---------------------- | ----------------------------------------- |
| [HTML](/analysis/languages/html/) |  |  |  |
| [XML](/analysis/languages/xml/) |  |  |  |
-In this section you will find the documentation related to language analyzers made and supported by SonarSource.
+In this section, you'll find documentation related to languages supported by SonarSource.
## What does analysis produce?
-{instance} can perform analysis on up to 27 different languages depending on your edition. The outcome of this analysis will be quality measures and issues (instances where coding rules were broken). However, what gets analyzed will vary depending on the language:
+SonarQube can analyze up to 27 different languages depending on your edition. The outcome of this analysis will be quality measures and issues (instances where coding rules were broken). However, what gets analyzed will vary depending on the language:
* On all languages, "blame" data will automatically be imported from supported SCM providers. [Git and SVN are supported automatically](/analysis/scm-integration/). Other providers require additional plugins.
* On all languages, a static analysis of source code is performed (Java files, COBOL programs, etc.)
## Will all files be analyzed?
-By default, only files that are recognized by a language analyzer are loaded into the project during analysis.
+By default, only files that are recognized by your edition of SonarQube are loaded into the project during analysis.
For example if you're using SonarQube Community Edition, which includes analysis of Java and JavaScript, but not C++, all `.java` and `.js` files would be loaded, but `.cpp` files would be ignored.
## What about branches and pull requests?
The SonarScanner for Ant provides a `task` to allow integration of SonarQube analysis into an Apache Ant build script.
-The SonarScanner for Ant is an Ant Task that is wrapper of [SonarScanner](/analysis/scan/sonarscanner/), which works by invoking SonarScanner and passing to it all [properties](/analysis/analysis-parameters/) named following a `sonar.*` convention. This has the downside of not being very Ant-y, but the upside of providing instant availability of any new analysis parameter introduced by a new version of a plugin or of SonarQube itself. Therefore, successful use of the SonarScanner for Ant requires strict adherence to the property names shown below.
+The SonarScanner for Ant is an Ant Task that is wrapper of [SonarScanner](/analysis/scan/sonarscanner/), which works by invoking SonarScanner and passing to it all [properties](/analysis/analysis-parameters/) named following a `sonar.*` convention. This has the downside of not being very Ant-y, but the upside of providing instant availability of any new analysis parameter introduced by a new version of SonarQube. Therefore, successful use of the SonarScanner for Ant requires strict adherence to the property names shown below.
## Use
<!-- /static -->
<update-center updatecenterkey="scannermaven"></update-center>
-The SonarScanner is recommended as the default analyzer for Maven projects.
+The SonarScanner for Maven is recommended as the default scanner for Maven projects.
The ability to execute the SonarQube analysis via a regular Maven goal makes it available anywhere Maven is available (developer build, CI server, etc.), without the need to manually download, setup, and maintain a SonarQube Runner installation. The Maven build already has much of the information needed for SonarQube to successfully analyze a project. By preconfiguring the analysis based on that information, the need for manual configuration is reduced significantly.
-
-
## Prerequisites
* Maven 3.x
* At least the minimal version of Java supported by your SonarQube server is in use
1. Your plugin does not compete with existing or soon-to-be-released SonarSource products (sorry, but we gotta pay the bills somehow).
1. It is analyzed on [SonarCloud](https://sonarcloud.io/) and the quality gate is green when doing a release.
1. It is compatible with the platform requirements (e.g. it runs on the minimum listed JRE).
-1. If your plugin adds analysis of a language which is not analyzed by any SonarSource analyzer you must provide the `NCLOC` and `NCLOC_DATA` [metrics](/user-guide/metric-definitions/), which are both required for a consistent user experience. You can take a look at how those metrics are provided for Java ([NCLOC](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/Measurer.java#L109), [NCLOC_DATA](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/ast/visitors/FileLinesVisitor.java#L101)).
+1. If your plugin adds analysis of a language which is not analyzed by SonarQube you must provide the `NCLOC` and `NCLOC_DATA` [metrics](/user-guide/metric-definitions/), which are both required for a consistent user experience. You can take a look at how those metrics are provided for Java ([NCLOC](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/Measurer.java#L109), [NCLOC_DATA](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/ast/visitors/FileLinesVisitor.java#L101)).
1. Last but not least: your plugin must be aligned with the goal of the SonarQube platform: management of the technical debt and the quality of the code.
To be more precise: every feature of SonarQube is tied to the code, so if your plugin provides data that can't be attached to a source or a test file, then there are chances that your plugin won't be accepted in the Marketplace
You can mark individual issues False Positive or Won't Fix through the issues interface. If you're using PR analysis provided by the Developer Edition, issues marked False Positive or Won't Fix will retain that status after merge. This is the preferred approach.
**//NOSONAR**
-Most language analyzers support the use of the generic mechanism: `//NOSONAR` at the end of the line of the issue. This will suppress the all issues - now and in the future - that might be raised on the line.
+For most languages, SonarQube supports the use of the generic mechanism: `//NOSONAR` at the end of the line of the issue. This will suppress all issues - now and in the future - that might be raised on the line.
## How do I find and remove projects that haven't been analyzed in a while?
In **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management)** you can search for **Last analysis before** to filter projects not analyzed since a specific date, and then use bulk **Delete** to remove the projects that match your filter.
Only users who subscribe themselves will get notifications. With only one exception, there is no admin functionality to proactively subscribe another user. If you believe a user should be receiving notifications, then it's time to practice the gentle art of persuasion.
### The exception
-Notifications will automatically (without user opt-in) be sent to users with Quality Profile Administration rights when built-in Quality Profiles are updated. These updates can only happen via an upgrade of the relevant analyzer. This type of notification is on by default, and can be toggled globally in **[Administration > General Settings > General](/#sonarqube-admin#/admin/settings/)**.
+
+Notifications will automatically (without user opt-in) be sent to users with Quality Profile Administration rights when built-in quality profiles are updated. These updates can only happen through updating SonarQube or updating a third-party analyzer. This type of notification is on by default, and can be toggled globally in **[Administration > General Settings > General](/#sonarqube-admin#/admin/settings/)**.
## Email Configuration
To configure the email server, go to **[Administration > General Settings > Email](/#sonarqube-admin#/admin/settings)**.
When {instance} notices that an analysis was performed with a profile that is different in some way from the previous analysis, a Quality Profile event is added to the project's event log. To see the changes in a profile, navigate to the profile (**Quality Profiles > [ Profile Name ]**), and choose **Changelog**. This may help you understand how profile changes impact the issues raised in an analysis.
-Additionally, users with Quality Profile administration privileges are notified by email each time a built-in profile (one that is provided directly by an analyzer) is updated. These updates can only be caused by analyzer updates.
+Additionally, users with Quality Profile administration privileges are notified by email each time a built-in profile is updated. These updates can be caused by updating SonarQube or updating third-party analyzers.
### Copy a profile from one SonarQube instance to another?
### Make sure I've got all the relevant new rules in my profile?
-Each time a language plugin update is released, new rules are added, but they won't appear automatically in your profile unless you're using a built-in profile such as _Sonar way_.
+Each time a new SonarQube version is released, new rules are added, but they won't appear automatically in your profile unless you're using a built-in profile such as _Sonar way_.
If you're not using a built-in profile, you can compare your profile to the built-in profile to see what new on-by-default rules you're missing.
The algorithm is AES 128 bits. Note that 256 bits cipher is not used because it's not supported by default on all Java Virtual Machines ([see this article](https://confluence.terena.org/display/~visser/No+256+bit+ciphers+for+Java+apps)).
1. **Generate the secret key**
-A unique secret key must be shared between all parts of the SonarQube infrastructure (server and analyzers). To generate it, go to **[Administration > Configuration > Encryption](/#sonarqube-admin#/admin/settings/encryption)** and click on Generate Secret Key.
+A unique secret key must be shared between all parts of the SonarQube infrastructure. To generate it, go to **[Administration > Configuration > Encryption](/#sonarqube-admin#/admin/settings/encryption)** and click on Generate Secret Key.
1. **Store the secret key on the SonarQube server**
* Copy the generated secred key to a file on the machine hosting the SonarQube server. The default location is _~/.sonar/sonar-secret.txt_. If you want to store it somewhere else, set its path through the `sonar.secretKeyPath` property in _$SONARQUBE-HOME/conf/sonar.properties_
* Restrict file permissions to the account running the SonarQube server (ownership and read-access only).
Set the [sonar.sources](/analysis/analysis-parameters/) property to limit the scope of the analysis to certain directories.
### File Suffixes
-Most language plugins offer a way to restrict the scope of analysis to files matching a set of extensions. Go to **Project Settings > General Settings > [Language]** to set the File suffixes property.
+For most languages, you can restrict the scope of analysis to files matching a set of extensions. Go to **Project Settings > General Settings > [Language]** to set the File suffixes property.
### Choosing Files
Your first line of defence having a well-defined set of files in your analysis is your `sonar.sources` value. For projects built and analyzed with Maven, Gradle, or MSBuild, this value is defined automatically with a generally thorough, yet sane value. For other projects, you want to make sure `sonar.sources` is set to your project _sub-directory_ that actually contains your source files. Setting it to `.` will cast a wider net than most people intend.
### Java
SonarQube scanners require version 8 or 11 of the JVM and the SonarQube server requires version 11. Versions beyond Java 11 are not officially supported.
-The SonarQube Java analyzer is able to analyze any kind of Java source files regardless of the version of Java they comply to.
+SonarQube is able to analyze any kind of Java source files regardless of the version of Java they comply to.
We recommend using the Critical Patch Update (CPU) releases.
1. Creating the following volumes helps prevent the loss of information when updating to a new version or upgrading to a higher edition:
- `sonarqube_data` – contains data files, such as the embedded H2 database and Elasticsearch indexes
- `sonarqube_logs` – contains SonarQube logs about access, web process, CE process, and Elasticsearch
- - `sonarqube_extensions` – contains plugins, such as language analyzers
+ - `sonarqube_extensions` – contains external plugins
Create the volumes with the following commands:
```bash
* On first analysis of a project or branch
* When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated)
-* When the analyzer has just been upgraded (because rule implementations could be smarter now)
+* When SonarQube has just been upgraded (because rule implementations could be smarter now)
* When the rule is external
As a consequence, it is possible that backdating will keep newly raised issues out of New Code.
url: /user-guide/rules/
---
## Overview
-In {instance}, analyzers contribute rules which are executed on source code to generate issues. There are four types of rules:
+SonarQube executes rules on source code to generate issues. There are four types of rules:
* Code Smell (Maintainability domain)
* Bug (Reliability domain)
* Vulnerability (Security domain)
## Rules
-By default, when entering the top menu item "Rules", you will see all the available rules brought by the analyzers <!-- sonarqube -->installed on your {instance} instance<!-- /sonarqube --><!-- sonarcloud -->available on SonarCloud<!-- /sonarcloud -->. You have the ability to narrow the selection based on search criteria in the left pane:
+By default, when entering the top menu item "Rules", you will see all the available rules installed on your SonarQube instance. You have the ability to narrow the selection based on search criteria in the left pane:
* **Language**: the language to which a rule applies.
* **Type**: Bug, Vulnerability, Code Smell or Security Hotspot rules.
* **Tag**: it is possible to add tags to rules in order to classify them and to help discover them more easily.
-* **Repository**: the engine/analyzer that contributes rules to {instance}.
-* **Default Severity**: the original severity of the rule - as defined by the analyzer that contributes this rule.
+* **Repository**: the engine/analyzer that contributes rules to SonarQube.
+* **Default Severity**: the original severity of the rule - as defined by SonarQube.
* **Status**: rules can have 3 different statuses:
* **Beta**: The rule has been recently implemented and we haven't gotten enough feedback from users yet, so there may be false positives or false negatives.
* **Deprecated**: The rule should no longer be used because a similar, but more powerful and accurate rule exists.
* **Ready**: The rule is ready to be used in production.
-* **Available Since**: date when a rule was first added on {instance}. This is useful to list all the new rules since the last upgrade of a plugin for instance.
+* **Available Since**: date when a rule was first added on SonarQube. This is useful to list all the new rules since the last upgrade of a plugin for instance.
* **Template**: display rule templates that allow to create custom rules (see later on this page).
* **Quality Profile**: inclusion in or exclusion from a specific profile
## What do Security Reports show?
Security Reports quickly give you the big picture on your application's security, with breakdowns of just where you stand in regard to each of the [OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10), and [SANS Top 25](https://www.sans.org/top25-software-errors) categories, and [CWE](https://cwe.mitre.org/)-specific details.
-The Security Reports are fed by the analyzers, which rely on the rules activated in your Quality Profiles to raise security issues. If there are no rules corresponding to a given OWASP category activated in your Quality Profile, you will get no issues linked to that specific category and the rating displayed will be A. That won't mean you are safe for that category, but that you need to activate more rules (assuming some exist).
+The Security Reports rely on the rules activated in your Quality Profiles to raise security issues. If there are no rules corresponding to a given OWASP category activated in your Quality Profile, you will get no issues linked to that specific category and the rating displayed will be A. That won't mean you are safe for that category, but that you need to activate more rules (assuming some exist).
## What's the difference between a Security Hotspot and a Vulnerability?
You might not see any Vulnerabilities or Security Hotspots for the following reasons:
* You don't have any because the code has been written without using any security-sensitive API.
* Vulnerability or Security Hotspot rules are available but not activated in your Quality Profile so no Security Hotspots or Vulnerabilities are raised.
-* The analyzer for your language might only currently offer a few rules and won't raise any or only a small number of Vulnerabilities or Security Hotspots.
+* SonarQube might only offer a few rules for your language and won't raise any or only a small number of Vulnerabilities or Security Hotspots.
projects / sonarqube.git / commitdiff