Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Junit result xml files are not being generated for versions > 3.0.98 #64

Closed
kabilanmani93 opened this issue Apr 3, 2023 · 9 comments
Closed

Comments

@kabilanmani93
Copy link

kabilanmani93 commented Apr 3, 2023

Dotnet Project

Docker base image used : mcr.microsoft.com/dotnet/sdk:6.0.405-alpine3.17

Command used:
dotnet test --test-adapter-path:. --collect "Code Coverage" /p:CollectCoverage=true /p:CoverletOutputFormat="opencover" /p:CoverletOutput=tests/TestResults /p:UseSourceLink=true --logger:"junit;LogFileName=junit-result.xml;MethodFormat=Class;FailureBodyFormat=Verbose" --logger "trx;LogFileName=testresults.trx;Parser=Legacy" --results-directory valid/

Issue:
Junit result xml files are not being generated for versions > 3.0.98

But if either we REMOVE the flag --collect "Code Coverage" then the junit xml's are generated
or
instead pass --collect "XPlat Code Coverage" then the junit xml's are generated

having --collect " code coverage" the junt result xmls are not generated

@Siphonophora
Copy link
Collaborator

@kabilanmani93 So, files were generated on v3.0.87?

--collect "Code Coverage" doesn't alter the xml report that we generate, right? Maybe it adds standard output that gets logged in our report?

It isn't obvious to me how these could be interfering with each other, so I think we may need an example to move this forward. Unless

@codito
Copy link
Contributor

codito commented Jul 6, 2023

@kabilanmani93 I had a chance to debug a similar issue recently. It was with coverlet collector. The problem is Coverlet also instruments the Spekt.* dlls which changes some of the event handlers.

Is it possible to try excluding Spekt.* and JUnitXml* dlls from code coverage instrumentation?

If this doesn't work, could you share the log.* files generated with dotnet test --diag:log.txt command?

@chrisandchris
Copy link

I can confirm this behaviour:

  • 🚫 with XPlat Code Coverage (coverlet collector 6.0.0) and Junit Logger 3.0.110, no xml files are generated
  • 🆗 with XPlat Code Coverage (coverlet collector 6.0.0) and Junit Logger 3.0.98, the xml files are generated
  • 🚫 with MS Code Coverage 17.7.2 and Junit Logger 3.0.110, no xml files are generated
  • 🆗 with MS Code Coverage 17.7.2 and Junit Logger 3.0.98, the xml files are generated

We currently just made sure that 3.0.98 is installed and then we have the xml log files.

@codito
Copy link
Contributor

codito commented Sep 1, 2023

Thanks @chrisandchris for confirmation. Is it possible to share the log.* files generated with dotnet test --diag:log.txt command?

@robrich
Copy link

robrich commented Dec 30, 2023

@chrisandchris
Copy link

Thanks @chrisandchris for confirmation. Is it possible to share the log.* files generated with dotnet test --diag:log.txt command?

Sorry for the very late response. We stayed on 3.0.98 and then somehow we forgot to generate the logs.

Following command:

dotnet test --no-restore \
    --no-build \
    --test-adapter-path:. \
    --diag:log.txt \
    --collect:"Code Coverage;Format=cobertura" \
    --logger "junit;LogFilePath=./junit-{assembly}.xml;MethodFormat=Class;FailureBodyFormat=Verbose"

With JunitXml.TestLogger 3.0.134, i have the following log.txt: log.txt

However, I could not reliably reproduce the issue with the missing junit-xml. It worked on my machine, but our Gitlab Runner did not produce it. I'll investigate further (hopefully a bit faster...).

@timo-reymann
Copy link

timo-reymann commented Jan 29, 2024

@chrisandchris I find myself in the same situation, just with the Xunit XML logger. Also works locally, but not on the GitLab runners.

For some reason after a few builds it magically starts to work. In CI obviously the build only runs once, and all files are thrown aways as it runs in a container.

Maybe you have the same situation?

I can reproduce it by dotnet clean, run a build and than run dotnet test --no-build locally.

@codito
Copy link
Contributor

codito commented Feb 9, 2024

We found that code coverage instrumentation is messing up the test result reporting callbacks. Please check if this workaround helps: #72 (comment). If anyone tries this, please report back if the workaround helped.

Tracking a fix in above issue.

@codito
Copy link
Contributor

codito commented Feb 10, 2024

@codito codito closed this as completed Feb 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants