* Automatic Issue Assignment
* code annotation (blame data) in the Code Viewer
-* SCM-driven detection of new code (to help with Fixing the Water Leak). Without SCM data, SonarQube determines new code using analysis dates (to timestamp modification of lines).
+* SCM-driven detection of new code (to help with [Fixing the Water Leak](/fixing-the-water-leak)). Without SCM data, SonarQube determines new code using analysis dates (to timestamp modification of lines).
### Turning it on/off
SCM integration requires support for your individual SCM provider. Git and SVN are supported by default. <!-- sonarqube -->For other SCM providers, see the Marketplace.<!-- /sonarqube -->
* will disappear quickly
* will be merged rapidly to prevent integration issues
* is developed for a given version, so the version does not change,
- and there is no Leak Period concept as such; it's all leak period
- tracks all the new issues related to the code that changed on it.
+ and there is no New Code period concept as such; it's all new code
+* tracks all the new issues related to the code that changed on it.
Then, at each subsequent analysis of the long-lived branch, any new issue that comes from a short-lived branch automatically inherits the attributes (type, severity, ...) the issue had in the short-lived branch. A comment is added to the change log of the issue on the long-lived branch: "The issue had been copied from branch 'the short-live branch' to branch yyy".
-## Leak Period
+## New Code Period
-Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the Leak Period of a long-lived branch in **Administration > Branches**.
+Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the New Code period of a long-lived branch in **Administration > Branches**.
## Settings and Quality Profiles on Branches
Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch.
-## Leak Period
+## New Code Period
-The ephemeral nature of short-lived branches means no explicit Leak Period is necessary; it's all new code. Thus, no "new code" data is available for a short-lived branch.
+The ephemeral nature of short-lived branches means no explicit New Code Period is necessary; it's all new code.
## Settings and Quality Profiles on Branches
<!-- sonarqube -->SonarQube<!-- /sonarqube --><!-- sonarcloud -->SonarCloud<!-- /sonarcloud --> offers two main tools to help you find your leaks:
-* Leak Period metrics show the variance in your measures between the current code and a specific point you choose in its history, typically the `previous_version`
-* New Code is primarily detected based on SCM "blame" data (starting from the first analysis within your Leak Period), with fallback mechanisms when needed. See SCM integration for more details.
+* New Code metrics show the variance in your measures between the current code and a specific point you choose in its history, typically the `previous_version`
+* New Code is primarily detected based on SCM "blame" data starting from the first analysis within your New Code Period (formerly the "Leak Period"), with fallback mechanisms when needed. See [SCM integration](/analysis/scm-integration) for more details.
* [Quality Gates](/quality-gates) allow you to set boolean thresholds against which your code is measured. Use them with differential metrics to ensure that your code quality moves in the right direction over time.
## Use the Best Quality Gate Configuration
-The quality gate "Sonar way" is provided by SonarSource, activated by default and considered as built-in and so read-only. It represents our view of the best way to implement the Fixing the Water Leak concept. At each SonarQube release, we adjust automatically this default quality gate according to SonarQube's capabilities.
+The quality gate "Sonar way" is provided by SonarSource, activated by default and considered as built-in and so read-only. It represents our view of the best way to implement the [Fixing the Water Leak](/fixing-the-water-leak) concept. At each SonarQube release, we adjust automatically this default quality gate according to SonarQube's capabilities.
Three metrics allow you to enforce a given Rating of Reliability, Security and Maintainability, not just overall but also on new code. These metrics are recommended and come as part of the default quality gate. We strongly advise you to adjust your own quality gates to use them to make feedback more clear to your developers looking at their quality gate on their project page.
Each Quality Gate condition is a combination of:
* measure
-* period: **Value** (to date) or **Leak** (differential value over the Leak period)
+* period: **Value** (to date) or **New Code** (differential value over the New Code period)
* comparison operator
* warning value (optional)
* error value (optional)
-For each Quality Gate condition you must choose the metric to be tested, the threshold at which to raise a warning or error, and whether or not to apply the condition to all code or only to Leak Period code (irrelevant for conditions "on New Code").
+For each Quality Gate condition you must choose the metric to be tested, the threshold at which to raise a warning or error, and whether or not to apply the condition to all code or only to New Code period (irrelevant for conditions "on New Code").
---
projects / sonarqube.git / commitdiff