Pull requests analysis returns ERROR but master and feature branches are green

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.

Thank you.


Welcome to the community!

What does SonarQube say about why your PR Quality Gate is failing?


So I get the 5 following warnings:

  • 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.


Thanks for sharing the warnings you see. Since they are just warnings, I think we can ignore them in this thread.

Regarding coverage, I’ll start with the dumb question: are you generating coverage reports for your PRs?

After that, it’s going to be a question of your analysis configuration. Does it vary between branches & PRs?


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’

Could it be simply a path problem?


Does that mean that sometimes it doesn’t show 0%?

Quite possibly. I’m struck by your paths:

Do your file and directory names really have asterisks (’*’) in them? Because… you know that’s a wildcard character, right?


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 :slight_smile:


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.