]> source.dussan.org Git - sonarqube.git/commitdiff
DOC-89 Improve linking to coverage docs (#6501)
authorPeeter Piegaze <61758048+peeter-piegaze-sonarsource@users.noreply.github.com>
Mon, 22 Aug 2022 15:04:41 +0000 (17:04 +0200)
committersonartech <sonartech@sonarsource.com>
Mon, 22 Aug 2022 20:03:13 +0000 (20:03 +0000)
server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-gradle.md
server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-maven.md
server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-msbuild.md

index 710501a67478aabae78266021e941c0484b6c4f1..df67881f7418683d9fc678773a7b39555972d8f0 100644 (file)
@@ -90,7 +90,7 @@ project(":project2") {
 ```
 
 ## Task dependencies
-All tasks that produce output that should be included in the SonarQube analysis need to be executed before the `sonarqube` task runs. Typically, these are compile tasks, test tasks, and code coverage tasks. 
+All tasks that produce output that should be included in the SonarQube analysis need to be executed before the `sonarqube` task runs. Typically, these are compile tasks, test tasks, and [code coverage](/analysis/coverage/) tasks. 
 
 Starting with v3.0 of the SonarScanner for Gradle, task dependencies are no longer added automatically. Instead, the SonarScanner plugin enforces the correct order of tasks with `mustRunAfter`. You need to be either manually run the tasks that produce output before `sonarqube`, or you can add a dependency to the build script: 
 
@@ -208,4 +208,3 @@ Let's take a closer look at the `sonarqube.properties` `{}` block. As we have al
 Entries in the properties map can be read and written with the usual Groovy syntax. To facilitate their manipulation, values still have their “idiomatic” type (File, List, etc.). After the sonarProperties block has been evaluated, values are converted to Strings as follows: Collection values are (recursively) converted to comma-separated Strings, and all other values are converted by calling their `toString()` methods.
 
 Because the `sonarProperties` block is evaluated lazily, properties of Gradle's object model can be safely referenced from within the block, without having to fear that they have not yet been set.
-
index 79fa78b392baee0a496e9ca8f81e8915a1969a94..8ab27b24dd570ef389fd26a0fccce538dedd0eee 100644 (file)
@@ -64,7 +64,7 @@ To specify the version of sonar-maven-plugin instead of using the latest:
 mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar
 ```
 
-To get coverage information, you'll need to generate the coverage report before the analysis
+To get coverage information, you'll need to generate the coverage report before the analysis and specify the location of the resulting report in an analysis parameter. See [Test Coverage](/analysis/coverage/)for details.
 
 ## Configuring Analysis
 Most analysis properties will be read from your project. If you would like override the default values of specify additional parameters, configure the parameter names found on the [Analysis Parameters](/analysis/analysis-parameters/) page in the `<properties>` section of your pom.xml like this:
index 2fc4faa9c8517ee48d698321e300332f2099c3b5..35372bb596603deb89b102714bdd741a752abc79 100644 (file)
@@ -191,7 +191,7 @@ For detailed information about all available parameters, see [Analysis Parameter
 | If your build process cannot tolerate these changes we recommend creating a second build job for {instance} analysis.\r
 \r
 ### Build\r
-Between the `begin` and `end` steps, you need to build your project, execute tests and generate code coverage data. This part is specific to your needs and it is not detailed here.\r
+Between the `begin` and `end` steps, you need to build your project, execute tests and generate code coverage data. This part is specific to your needs and it is not detailed here. See [.NET Test Coverage](/analysis/test-coverage/dotnet-test-coverage/) for details.\r
 \r
 ### End\r
 The end step is executed when you add the "end" command line argument. It cleans the MSBuild/dotnet build hooks, collects the analysis data generated by the build, the test results, the code coverage and then uploads everything to {instance}\r
@@ -221,16 +221,7 @@ Parameter|Description
 \r
 ## Code Coverage\r
 \r
-In a Azure DevOps / TFS environment, test files are automatically retrieved following this search\r
-* Search for .trx files in any TestResults folder located under the $Build.SourcesDirectory path\r
-* If not found, then a fallback search is made against $Agent.TempDirectory\r
-\r
-Once trx files have been found, their `.coverage` counterpart are searched as well and the scanner tries to convert them to `.coveragexml` files that will be uploaded to {instance}.\r
-CodeCoverage.exe tool is used for that, and the scanner also needs to find a path to that tool, following this search path\r
-* Search for the presence of `VsTestToolsInstallerInstalledToolLocation` environment variable, set by the VsTestToolsPlatformInstaller task or by the user\r
-* If not found, search for either the presence of that tool in well-known installation path, or via the registry.\r
-\r
-As stated above, this will work only with the .NET 4.6 flavor of the Scanner.\r
+See [.NET Test Coverage](/analysis/test-coverage/dotnet-test-coverage/) for details.\r
 \r
 ## Excluding projects from analysis\r
 \r