-
Notifications
You must be signed in to change notification settings - Fork 321
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
Coverage report file duplicated when using --logger option #2334
Comments
@jakubch1 this is CC related, please have a look 🙂 |
Or maybe @MarcoRossignoli if this is coverlet related? Thx |
I dont' think it's related to coverlet, collectors(wrote by @vagisha-nidhi) only send artifact through data sink https://github.com/tonerdo/coverlet/blob/master/src/coverlet.collector/DataCollection/AttachmentManager.cs#L146 We don't handle nothing about loggers. |
I'm experiencing the same thing (also using coverlet)... each xml file is duplicated. |
Is there any solution found for this issue? |
Still experiencing this |
I noticed the same if I use a .runsettings configuration file. But if I use the argument directly in an Azure Pipeline task:
The problem just disappear (This works also locally. The problem is the logger tag in the in the .runsettings file). |
I'm having the same problem with |
I have the same problem with a pretty basic command:
|
@nohwnd @MarcoRossignoli @jakubch1 What can we do about it? |
This issue is still open after more than one year.... |
The behavior is expected, trx logger currently creates a file and a directory like: TestResult/userName_machineName_timespan<- folder all attachments generated by the test session are copied inside the For this reason at the end of the test inside the subdirectories of If you need to publish coverage report using
If the issue affect also other scenarios one possible solution could be add a new parameter to the logger like |
I spent the morning digging into the most recent changes to code coverage processing. Here's what I've found:
I would suggest that we rework the code coverage publishing to be like test files. We publish them into a staging folder that removes the duplicate files and can be picked up by codecov.io bash file. Docs https://docs.codecov.com/docs/about-the-codecov-bash-uploader |
@SteveBush can you link here the documentation of codeconv.io related to the code coverage publishing workflow? |
Updated with codecov.io reference and like to docs. |
After the internal discussion we decided to not take any action for the moment as the behavior is as-designed and expected. TL;DR;
For the two reason above we think that the issue is more related to "how the artifacts are searched and loaded" after the generation. Our advice is to use minimatch patterns to correctly include/exclude assets to elaborate/upload. |
It might be easier if I explain my current build structure and the challenges I'm facing. My build targets multiple frameworks. Builds artifacts are outputted to root level bin and obj directories in the following format:
I would like to use a similar format for TestResults. However, I haven't found a way to associate a test result with a targetframework or buildconfiguration MSBuild property. Also, duplicate versions of the same test output file are being produced in a random GUID folder. Ideally, I could modify the TestResults output folder to include the project name, build configuration, and target framework information and output results to the solution root. Current Challenges:
Ideally, I could find a way to output TestResults to the solution root in the following format:
To accomplish this, I would need to be able to TestResult output location based on MS build properties: I know I can set the test results directory on the dotnet test command line or in a test.runsettings file. However, I haven't found a MSBuild test output property that I can construct using MSbuild properties: Thanks for listening. Below is my current build structure and the contents of my root level Directory.Build.props file.
|
Thanks @SteveBush for the info. I'll label this one as by-design and I'll close for now. Looks like your problem is not strictly related to the "duplication issue" but more on the possibility to generate deterministic assets name that include os/tfm/architecture in it, where a possible solution could be provide the template name feature. We have already some related issues I'll add your description there. cc: @nohwnd |
My simple solution is to perform the delete step after the dotnet build.
|
Please see the reported issue here coverlet-coverage/coverlet#733 about using --logger option in conjunction with --collect:"XPlat Code Coverage".
We think that it should be related more with vstest than coverlet.
Is it an expected behavior to get two generated code coverage file instead of one if we use vstest logger option?
The text was updated successfully, but these errors were encountered: