Azure DevOps: publish quality gate in PR build - No analyses found in this build!

Sonarqube version: Developer EditionVersion 8.1 (build 31237)
Azure DevOps version: 2019.1 Version Dev17.M153.3

Task : Prepare Analysis Configuration
Version : 4.9.0

Task : Publish Quality Gate Result
Version : 4.8.1

SonarScanner for MSBuild 4.8


This seems to happen only in PR build validation. Works for master and branch build.
Task "Publish Quality Gate Result " reports “##[warning]No analyses found in this build! Please check your build configuration.”

In the “Prepare Analysis Configuration” step i can see that the path used for “report-task.txt” but its different than the “Publish Quality Gate Result” expects.

“Prepare Analysis Configuration” uses:

“Publish Quality Gate Result” looks for:

##[debug]adjustedPattern: 'D:\BA\B1\_work\_temp\sonar\2020.03.11.1-merge\**\report-task.txt'

This seems to be the case with the MSBuild scanner, standalone scanner works in PR builds.
The build is in Azure DevOps 2019.1.

Hi @tkoosaar,

Where does the -merge comes from ? Is that a build name ? Something else ?

Do you have multiple build running concurrently ?


For a single PR we may have several builds and in this scenario we have 2 builds where each does its own sonarqube analysis and pushes it into separate project in sonarqube (SPA angular client) and .NET core backend api.
The PR should reflect and show 2 quality gate passes/failures.
I dont know where -merge comes. However, on build in the PR is without -merge and the other one is with -merge.
Making sure notification kicks off @mickaelcaro .

When i compare the prepare and publish steps, then i can see that the the following property is correct on both:

However, when the pattern is defined to search for file, it goes off wrong.
##[debug]pattern: ‘sonar\2020.03.25.1-merge*\report-task.txt’
##[debug]findPath: ‘D:\BA\B1_work_temp\sonar\2020.03.25.1-merge’
##[debug]statOnly: ‘false’
##[debug]findPath: ‘D:\BA\B1_work_temp\sonar\2020.03.25.1-merge’
##[debug]applying include pattern
##[debug]adjustedPattern: 'D:\BA\B1_work_temp\sonar\2020.03.25.1-merge*

Why isnt it using the metadataFilePath instead?
I think it is using “##[debug]Build.BuildNumber=2020.03.25.1-merge” but we dont set this in PR builds.


When i add a step before the publish to fix up the Build.BuildNumber, then the publish works.
So workaround:

  • pwsh: |
    Write-Host “Current build number: $Env:Build_BuildNumber”
    $removeMerge = “$Env:Build_BuildNumber”
    $removeMerge = $removeMerge.Replace("-merge","")
    Write-Host “##vso[task.setvariable variable=Build.BuildNumber;]$removeMerge”
    condition: and(succeeded(), eq(variables[‘Build.Reason’], ‘PullRequest’))

I run it only within PR. i now have the result in build summary.

My problem is still that there is only one Quality Gate Status within the PR. It doesnt show one per build that is running within the PR!. So if one passes and other fails, i want to see that in PR and the combined result should be consistently failed (if theres one status).

Glad to hear that it works, but i don’t think that this is a good practice to fix the build number during the build though.

For your second point, yes, it’s “normal” because we don’t currently support PR decoration that comes from multiple builds, the latest one to be completed will erase the previous one. We are working on it.


Great to hear you are working on the nr2.
Im not happy with the workaround either and its not a great practice.

The scenario here is that the we have Client API and SPA / Angular client and these are tightly related to eachother. We have one repo for it and we used to have one build for it.
Unfortunately to get analysis for angular build and .net core build at the same time, it was not possible, so we had to split it into 2 builds and pushing to 2 different projects in sonarqube.

The .net core one uses msbuild scanner and the angular build uses standalone scanner. Even this has caveats as we are finding out :frowning:

And when splitting those 2 builds, do you have kind of a link between them that could have lead to the -merge suffix ? I did some researches but couldn’t find something about it.

The pattern we use is unique per build number as you have seen above, so each build should be able to find it’s own report that has been generated (or multiple one when we will be supporting that use case).

Actually, i think we may be causing this indeed. Thank you for pointing it out. i think i can see whats happening now and can fix the root cause.
To add details, we had a step that run even for PR builds that added branch name to build number for only .net core builds. This step wasnt necessary for PR builds.

Do you have any timeline for the multi-build in PR pipeline and individual or combined status in PR?