Task : Prepare Analysis Configuration
Version : 4.9.0
Task : Publish Quality Gate Result
Version : 4.8.1
SonarScanner for MSBuild 4.8
Problem
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.
Hi,
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 .
Taavi
When i compare the prepare and publish steps, then i can see that the the following property is correct on both:
sonar.scanner.metadataFilePath":"D:\BA\B1\_work\_temp\sonar\2020.03.25.1\341060fb-1145-b87f-d5c9-7f5c22ae6e50\report-task.txt
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*\report-task.txt’
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.
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
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.host.url":"https://sonarcloud.io/","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":"https://dev.azure.com/XX-XX/","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: https://sonarcloud.io/dashboard?id=xxx&pullRequest=xxx
Publish Quality Gate Result: Agent.TempDirectory=D:\Agents\S4\_work\_temp 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?
@zamojski
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.
