Closed sureshtadisetty closed 4 years ago
Hi Suresh,
yes, unfortunately this is currently a known issue in the backend of Azure DevOps Services. The respecting team is already working on a fix. In the meantime you can send us your organization name you use in Azure DevOps, so we can apply a change which will resolve the issue for you until the fix is rolled out across the regions.
Best Lukas
Thanks for confirming Lukas!
ADO org I'm working in is 'Office'
Hello Lukas,
We are facing the same problem since 1-Nov, can you please get the fix applied for Org: "dynamicscrm" Project: "OneCRM" as well.
Thanks & Regards Sandeep DK
Hi @sandeepdk,
I asked the Azure DevOps team to apply the workaround for your org as well. This should fix the issue within the day.
René
@sandeepdk, @sureshtadisetty the change has been applied to both of your organizations. Please have a look if everything runs smoothly now.
Best Lukas
@ReneSchumacher, @woehrl01 thanks for the same, i confirm that the same is working on our build pipelines.
Hello @woehrl01 ,
we have the same problem. Can you apply the fix to our organization "pundz" too? We have the problem since we updated pipelines to .NET Core SDK 3.1.100.
Thanks, Thomas
@thomashauser I just requested the workaround for your org. Should be done soon.
René
@thomashauser I just received the feedback that the workaround is always active in your organization. Could you please run your build again with the variables System.Debug and BQC.LogRawData set to true and send us the log files (the one from your test task, the publish coverage task (if used), and the BQC task) to PSGerExtSupport@microsoft.com?
Thanks! René
We verified issue is resolved for us. Thanks @woehrl01 @ReneSchumacher for quick turnaround!
We observed "dotnet test" publishing code coverage results only after the Agent job is completed. Build Quality checks task is waiting for code coverage results to be available for default 10 mins and timeout with message "Unable to get code coverage data within the maximum wait time."
Task completes successfully if we try rerun failed job, but fail if re-queued (same as above).
Is this a known issue?