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?

@mickaelcaro We’re facing the same issue but on SonarCloud and Azure DevOps cloud version. The build agent is hosted inside our company’s network. We have a regular build running on develop (long term branch) and it publishes quality gate result without any problems. However it doesn’t work for pull request validation build - the build is different but it uses the same settings. The report is being published in SonarCloud but not in Azure DevOps Extensions tab.

Prepare analysis on SonarCloud
set SONARQUBE_SCANNER_PARAMS={"":"","sonar.projectVersion":"[PR] XXX Configurator_merge_20200930.2","sonar.pullrequest.base":"develop","sonar.pullrequest.branch":"feature/xxx/downloadPanel","sonar.pullrequest.provider":"vsts","sonar.pullrequest.vsts.instanceUrl":"","sonar.scanner.metadataFilePath":"D:\\Agents\\S4\\_work\\_temp\\sonar\\[PR] XXX Configurator_merge_20200930.2\\9900c9fe-79e1-975a-366e-d697948cd8db\\report-task.txt"}

Run Code Analysis:
08:58:13.301 INFO: Analysis report uploaded in 249ms
08:58:13.305 DEBUG: Report metadata written to D:\Agents\S4\_work\_temp\sonar\[PR] XXX Configurator_merge_20200930.2\9900c9fe-79e1-975a-366e-d697948cd8db\report-task.txt
08:58:13.305 INFO: ANALYSIS SUCCESSFUL, you can find the results at:

Publish Quality Gate Result:
defaultRoot: 'D:\Agents\S4\_work\_temp'
findOptions.allowBrokenSymbolicLinks: 'false'
findOptions.followSpecifiedSymbolicLink: 'true'
matchOptions.nonull: 'false'
matchOptions.matchBase: 'false'
matchOptions.nocomment: 'false'
matchOptions.nonegate: 'false'
matchOptions.flipNegate: 'false'
pattern: 'sonar\[PR] XXX Configurator_merge_20200930.2\**\report-task.txt'
findPath: 'D:\Agents\S4\_work\_temp\sonar'
statOnly: 'false'
findPath: 'D:\Agents\S4\_work\_temp\sonar'
findOptions.allowBrokenSymbolicLinks: 'false'
findOptions.followSpecifiedSymbolicLink: 'true'
findOptions.followSymbolicLinks: 'true'
D:\Agents\S4\_work\_temp\sonar (directory)
D:\Agents\S4\_work\_temp\sonar\[PR] XXX Configurator_merge_20200930.2 (directory)
D:\Agents\S4\_work\_temp\sonar\[PR] XXX Configurator_merge_20200930.2\9900c9fe-79e1-975a-366e-d697948cd8db (directory)
D:\Agents\S4\_work\_temp\sonar\[PR] XXX Configurator_merge_20200930.2\9900c9fe-79e1-975a-366e-d697948cd8db\report-task.txt (file)
4 results
found 4 paths
applying include pattern
adjustedPattern: 'D:\Agents\S4\_work\_temp\sonar\[PR] XXX Configurator_merge_20200930.2\**\report-task.txt'
0 matches
0 final results
[SQ] Searching for sonar\[PR] XXX Configurator_merge_20200930.2\**\report-task.txt - found 0 file(s)
No analyses found in this build! Please check your build configuration.

I’ve also printed the D:\Agents\S4\_work\_temp directory content before executing Publish Quality Gate Result task and the file is there - D:\AGENTS\S4\_WORK\_TEMP\sonar\[PR] XXX Configurator_merge_20200930.2\9900c9fe-79e1-975a-366e-d697948cd8db\report-task.txt.

I don’t know how the paths are matched in the code but for me they’re matched. Any suggestions? Is it a bug in the Sonar Scanner task?

First of all thank you for the support you didn’t provide! :wink:

I found a way to workaround the issue on my side by removing [PR] prefix from build name. It looks like the special characters in glob expressions are not escaped neither on minimax nor your side. Please fix the issue in your Sonar Scanner in this line:

let matchResults: string[] = minimatch.match(findResults, pattern, matchOptions);
tl.debug(matchResults.length + " matches");

You have the test case in the above post.

1 Like

Thank you very much, I tested your solution to rename the build name, then the publish works now.
Unfornately, till Oct. 2022, the bug about the glob is still not fixed.