search

MicrosoftPremier / VstsExtensions

Documentation and issue tracking for Microsoft Premier Services Visual Studio Team Services Extensions
MIT License
56 stars 14 forks source link

Code coverage results waiting until timeout- again #237

Closed StephenWBertrand closed 3 weeks ago

StephenWBertrand commented 2 months ago

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 https://github.com/MicrosoftPremier/VstsExtensions/issues/236#issuecomment-2007285829 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:

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

StephenWBertrand commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 3 weeks ago

yeah seems to be working now.