Closed aolszowka closed 5 months ago
Hi @aolszowka,
thanks for reporting this and for providing a repro. I'm working on this right now to see what's going on here.
Hi again,
it took a while to make the repro work, because the simulation script mostly deleted the coverage from the first component, resulting in a higher coverage value. However, I could repro the issue and is caused by the way Azure DevOps handles coverage data.
Even though you keep publishing newer coverage files with each re-run, Azure DevOps only takes the first published file into account when it comes to the API. You can also see this on the build summary page, which still shows the old value. In the picture below, you see that I had two re-runs, and both (attempt 2 and 3) created increased coverage:
However, the summary page still shows the reduced coverage value:
Even though the code coverage tab, which is generated based on the latest published Cobertura file, shows the correct increased value:
In other words, unless we switch to custom coverage parsing in the BQC task, we cannot change that behavior. BQC just reads the values through the coverage API and it reports the wrong values (in this case).
@ReneSchumacher Thank you for looking into this.
However, the summary page still shows the reduced coverage value
This sounds like an Azure DevOps Bug, and at least the second one I've found on this specific page (the other is this one which I have been going around with Microsoft Support on for a few months now: https://github.com/MicrosoftDocs/azure-devops-yaml-schema/issues/212).
Is there any more direct link to the Team's Program Manager? Historically Donovan Brown sat up in build (I think it was //Build2016?) and proudly declared that if we had issues like this to hit him up on Twitter. Who is the current PM? Are they willing to have a conversation? I'd be happy to jump on the phone with them (we're a paying customer!).
For now we'll use the work around and we appreciate your efforts on this extension. I'm willing to have this issue closed out if you want. I wish we could fix some of the underlying issues and make everyone's life easier!
I'll see who's responsible for this part and try to connect you with the right contact. Since this is code coverage, I believe it should be the testing tools team, not the build/pipelines team. Will get back to you via email, as I don't want to share internal contact information broadly here in the issue 😉
@ReneSchumacher I hope you've had a wonderful Holiday Season, were you able to connect with someone? I can be reached at my username at gmail.
@aolszowka Thanks for pinging me again. I haven't received any feedback from PG yet, so I have now asked again. I have lost track of the topic over the holiday season and maybe so has the PG.
Describe the context
Describe the problem and expected behavior
When a pipeline is Reran (
Rerun failed jobs
)BuildQualityChecks@9
does not appear to account for the most recent Attempt when calculating code coverage.Screenshots to Follow:
In our production pipeline, we are being affected by what we believe to be a karama-reporter bug (not yet reported/evaluated), wherein, in scenarios not yet understood, we fail to get a code coverage report generated from our Angular Unit Tests.
This causes an issue in our pipeline because we combine the output of the
coverage.cobertura.xml
reports from both our Angular and .NET Core API to form a single report that is reported on for the purposes of this gate.Because there is a significant amount of variance between these two, when the Angular report fails to generate, we fail code coverage.
While we await research into the underlying bug, our developers have attempted to use the
Rerun failed jobs
to reattempt the build:However, we believe that
BuildQualityChecks@9
does not properly account for reruns, as we believe we are seeing the previous failing coverage numbers in its output. Because of this the pipeline will still continue to fail, even if the missing coverage report "shows up" on a subsequentAttempt
.This scenario can be reproduced by attempting to combine any two sets of code coverage and is not Angular specific.
Consider the following toy project layout (a zipped version is attached to this report and will also be emailed to the address provided):
Project Layout
azurepipeline.yml
CodeCoverageCheck.sln
CodeCoverageCheck.csproj
CodeCoverageToy.cs
CodeCoverageCheck.Tests.csproj
CodeCoverageToyTests.cs
CodeCoverageCheck.Tests2.csproj
CodeCoverageToy2Tests.cs
CodeCoverageCheck2.csproj
CodeCoverageToy2.cs
This can be a tricky to reproduce, I will attempt to describe how the above toy project works, in order to reproduce this scenario in a clean environment.
In order to simulate a "reporting failure" the following PowerShell Snippet is ran prior to combining the reports:
Which at a high level performs the following:
$(Agent.TempDirectory)
from the Pipeline Run--collect:"XPlat Code Coverage"
this will output the code coverage files to this location which is a well known variable https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml/home/vsts/work/_temp/_fv-az428-823_2023-10-24_22_06_42/In/fv-az428-823/
wherefv-az428-823
is the name of the Microsoft Hosted Build Agent assigned at Random, along with the timestamp of when the execution happened.coverage.cobertura.xml
files, create a lookup dictionary based on the hash of these files to help us understand the sets of files because we cannot rely on file names.CodeCoverageCheck.Tests2
test results reliably, however we do not believe there is a guarantee. It is hoped that the above coverage files are unbalanced enough to reproduce the scenario in all cases.To the reproduce the behavior after creating a pipeline one must:
BuildQualityChecks@9
will compare against.43.4783% (10/23 line)
BuildQualityChecks@9
to fail with31.25% (5/16 line)
Rerun failed jobs
on this EXISTING pipeline (do not run a new pipeline!). You may need to run this several times until you get a "successful" run that DOES NOT trigger the above PowerShell Logic (IE preserves all runs).A reproducing scenario might look something like this:
The Failed Pipeline Reruns will then look like this:
When in this state you can now validate that
BuildQualityChecks@9
appears to use only the initial run, as opposed to the additionalAttempts
.Work Around
Running a NEW pipeline (not
Rerun failed jobs
) will properly report, however this can be painful depending on the length of the pipeline (because it reruns all jobs, not just the failed ones).Task logs
I have held off providing these in lieu of providing the entire reproducing project above. Should you need these logs I would be happy to provide them.