Hi there,
having both master and feature branches passing the code analisys in green, when doing the analisys for the pull request (from feature branch to master) it returns this error message:
Number of analyses in this build: 1
Summary of statusses: “ERROR”
The analysis did not pass the quality gate because because at least one analysis has has the status ‘ERROR’. Attempting to fail the build
This message is returned by the Break build on quality gate task, which is on an on-prem Azure DevOps 2019, and Sonarqube is in the Enterprise Edition Version 8.9.1.
The SonarQube break build task version is 8.1.0.
The Run Code Analysis task version is 4.20.0
Any hint on what could be reviewed on our side could be really appreciate it.
SonarScanner will require Java 11 to run, starting in SonarQube 9.x. Please upgrade the version of Java that executes the scanner and refer to the documentation if needed.
The Azure DevOps server URL is missing in the SonarQube configuration. Please configure this parameter in the ALM integrations settings of your SonarQube server.
The Azure DevOps Project name is missing in the SonarQube configuration. Please configure this parameter in the SonarQube Project ALM settings.
The Azure DevOps Repository name is missing in the SonarQube configuration. Please configure this parameter in the SonarQube Project ALM settings.
Pull request decoration did not happen because the token is missing. Please set it in the project settings.
And regarding the error it’s mainly showing 0% of new code coverage while the rule established minimum of 80%,. BTW, the future branch only contains a new line in the yaml file.
There’s something weird happening here when reading the logs for the pull-request build.
This is part of the Run Code Analysis output (at the beginning of it):
Code coverage command line tool: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Team Tools\Dynamic Code Coverage Tools\CodeCoverage.exe
Property ‘sonar.cs.vstest.reportsPaths’ provided, skipping the search for TRX files in default folders…
Absolute path to coverage file: C:\Builds\1\868\s\TestResults*_VM0320_2021-09-24_10_47_00\In\VM0320*_VM0320_2021-09-24.10_46_54.coverage
The following code coverage attachments were found from the trx files: C:\Builds\1\868\s\TestResults*_VM0320_2021-09-24_10_47_00\In\VM0320*_VM0320_2021-09-24.10_46_54.coverage
Not using the fallback mechanism to detect binary coverage files.
Executing file C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Team Tools\Dynamic Code Coverage Tools\CodeCoverage.exe Args: analyze /output:C:\Builds\1\868\s\TestResults*_VM0320_2021-09-24_10_47_00\In\VM0320*_VM0320_2021-09-24.10_46_54.coveragexml C:\Builds\1\868\s\TestResults*_VM0320_2021-09-24_10_47_00\In\VM0320*_VM0320_2021-09-24.10_46_54.coverage
Working directory: C:\Builds\1\868\s\TestResults**_VM0320_2021-09-24_10_47_00\In\VM0320
Timeout (ms):60000
Process id: 11088
Process returned exit code 0
Coverage report conversion completed successfully.
The TFS Processor has finished
Using the supplied value for SONAR_SCANNER_OPTS. Value: -Xmx4024m
There in bold you can read the .coveragexml file path, but in the same log deep down you can read this:
INFO: Importing 21 Roslyn reports
INFO: Found 17 MSBuild C# projects: 8 MAIN projects. 8 TEST projects. 1 with no MAIN nor TEST files.
INFO: Sensor C# [csharp] (done) | time=1359ms
INFO: Sensor C# Tests Coverage Report Import [csharp]
WARN: Could not find any coverage report file matching the pattern ‘*.coveragexml’
The weird paths is what the Azure task outputs, but basically it masks the username that runs the task, so for your understanding the asterisks should be replaced by the name of the user
I’ve gone back to your previous post to take a slightly closer look at some of the lines, quote/modified below:
When I code-format these lines (``` on the line before the block and on the line after) it’s easier to see several mismatches: ‘.coverage’ vs ‘.coveragexml’; ‘**’ vs ‘* ’ vs '’ and possibly most importantly VM0320 vs the other two variations of the directory name. I think your next step in investigating this is getting Azure’s masking turned off so you can see/compare the full/real paths.