Code coverage results waiting until timeout- again

[StephenWBertrand]

• Extension: BuildQualityChecks
• Environment: Azure DevOps Services (cloud)
• Agent type: Microsoft-hosted
• Agent version: vmImage: 'ubuntu-latest'
• Pipeline type: yaml pipeline

Starting around April 23 we started seeing the dreading timeout in our pipelines when doing code coverage checks. It had been working fine for long time before. It seems similar to previous issues listed here.

Our original pipeline had just the DotNetCoreCLI@2 task to run our tests, and then BuildQualityChecks@8 to check. No extra publish steps or such.

After the problems started, we tried upgraded to BuildQualityChecks@9, no help. Then adding extra publish steps to mixed results.

Was able to get passed the timeout when using the original suggestion from issue #236 (comment)
to switch to "XPlat Code Coverage" and add the PublishCodeCoverageResults@2 step.

The fallout was that the "Code Coverage" tab in ADO no longer shows any report.

Is there any new updates related to this as to why it would just stop working? I'd hate to lose the report feature.

I've created 3 runs and emailed the logs
1 original pipeline
2 no-timeout-no-report (original suggestion from 236, 'XPlat')
3 final solution in 236 by customer using PublishTestResults@2 instead

Task logs
Run your pipeline with the following variables:

• For BuildQualityChecks: System.Debug and BQC.LogRawData set to true

Send the task log to PSGerExtSupport@microsoft.com and reference your GitHub issue.

[StephenWBertrand]

ok, well turns out the 2 (original suggestion from 236) is now working for me. I think I might have been canceling the build after I got through those steps.. and causing the ADO stuff to maybe not process and thus not show up in the UI. argh. going to test some more. Boy wish it just worked the way it did last week. :)

[ReneSchumacher]

Hi @StephenWBertrand,

I'm very sorry to see this happening again 😞. Afaik, the issue should have been resolved as it was caused by a misconfigured feature flag in one of our deployment rings. After fixing this, the DotNetCoreCLI task started triggering the coverage jobs and BQC was able to fetch coverage again. I'll check your logs to see if someone messed up the feature flag again.

[ReneSchumacher]

I have checked your logs and the feature flag looks good even in the failing run. So, the issue might have been caused by a performance degradation in Azure DevOps or maybe there was an intermittent issue with creating the coverage data. Can you see coverage data in the pipeline summary of the failed build?

[StephenWBertrand]

yeah seems to be working now.