Skip to content

Feature Request: New dotnet tool command for merging results in standalone mode #1015

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

Open
chaoticsoftware opened this issue Dec 14, 2020 · 12 comments
Labels
feature-request New feature request Priority:3 Nice to have stale

Comments

@chaoticsoftware
Copy link

N.B. Alert! :)
I just started looking into adopting coverlet for our code coverage purpose. We run tests across many different modules not only with parallelism within the test job, but also across several different jobs running in parallel in our pipeline. Having to run tests in serial would be a huge (and unacceptable) blow back to our pipeline latency. Aside from that, I've noticed from several threads in here that MergeWith has its issues right now, even when executing tests in parallel. So I have a feature request, that should be fairly easy to implement. In fact, I just prototyped it for myself:

Why not have a dotnet tool command for merging existing json reports into a single final report. That way one can still do a massively parallel testing, and just run the command to merge all the results together. That command seems to be performing well even if results are merged in a single thread, but ultimately if needed, can be further enhanced to work in a multi-threaded mode using concurrent dictionaries and what not to replace the existing single-threaded data structures that are used for representing the results.

So, the pipeline would look like this (an approximation of the actual syntax just to convey the point):

- job: Build
  steps:
     - dotnet build test.sln
- job: Test
  dependsOn: Build
  strategy:
    - parallel: n
  steps:
    - dotnet test test.sln --no-build --collect:"XPlat Code Coverage" -s ./test.runsettings
    - Copy ./**/coverage.json to $(build.artifactStagingDirectory)/cc
       Flatten: true
    - publish $(build.artifactStagingDirectory)/cc
      artifact: CC_$(System.JobPositionInPhase)
- job: CodeCoverage
  dependsOn: Test
  steps:
    - download
       patterns: 'CC_*'
       path: $(pipeline.workspace)/coverageResults
    - dotnet merge-coverage-reports $(pipeline.workspace)/coverageResults/**/coverage.json -o $(pipeline.workspace)/coverageResults/merged -f json,cobertura
    - publishCodeCoverage: $(pipeline.workspace)/coverageResults/merged

Does this sound reasonable?

@petli
Copy link
Collaborator

petli commented Dec 15, 2020

You can solve this now by configuring Coverlet to output e.g. cobertura or opencover files instead of it's own format, and then use https://github.com/danielpalme/ReportGenerator to merge them into a single result (as well as applying additional filtering of the results if desired).

(It has been discussed to add separate merge steps, but I can't find the issue for that now.)

@MarcoRossignoli MarcoRossignoli added the feature-request New feature request label Dec 15, 2020
@MarcoRossignoli
Copy link
Collaborator

FYI @jakubch1

@chaoticsoftware
Copy link
Author

You can solve this now by configuring Coverlet to output e.g. cobertura or opencover files instead of it's own format, and then use https://github.com/danielpalme/ReportGenerator to merge them into a single result (as well as applying additional filtering of the results if desired).

(It has been discussed to add separate merge steps, but I can't find the issue for that now.)

Thanks for the suggestion. I agree. Certainly it is possible to do so. There are a couple of things that I'd say to that, which in my opinion makes the flow less than ideal:

  1. I need to get the report generator from marketplace and depending on the organization that could mean trouble going through approval process. Not an engineering problem, but a very real one in practice.

  2. You already have the logic to merge the reports, and it seems like an easy next step to do. Wouldn't it be just cleaner and more efficient if you had to use one tool as opposed to two? I mean if dotnet test, for instance, were to provide the same functionality that coverlet provides, but in a built-in fashion, there is little doubt in my mind that engineers would opt to use that built-in functionality instead of adding a dependency to coverlet. Wouldn't you agree? Same can be said about coverlet being self-sufficient as opposed to relying on an external tool to finish its job for it. In the end all the engineer cares about is having their code coverage. All these different steps that take place under the hood are just the bi-product of our toolset limitations IMHO.

@MarcoRossignoli
Copy link
Collaborator

It has been discussed to add separate merge steps, but I can't find the issue for that now.)

This was the discussion #683 (comment)

could mean trouble going through approval process.

Report generator is used also by AzDo https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-150-update#cobertura-code-coverage-report-updates
FYI if you need some proof in your approval process

@jakubch1
Copy link
Contributor

As part of this: microsoft/vstest#1811 effort we will also add extensibility for other data collectors (for example coverlet). Then we also want to onboard coverlet to this logic.

At the end running dotnet test --collect "XPlat Code Coverage" should generate 1 coverage report with merged information even when running in parallel.

@chaoticsoftware
Copy link
Author

Thanks @jakubch1 - what is the current timeline on delivering the work? When is 16.9.0?

Also I'm assuming that it would mean reports from a single dotnet test would be merged into one file, but if I run multiple instances as in parallel Azure Pipeline jobs for instance, I'd still need to merge myself. Any chance that this utility would be made available for external use too?

@jakubch1
Copy link
Contributor

Adding @cvpoienaru who is working on the change.

@github-actions
Copy link

github-actions bot commented Oct 1, 2023

This issue is stale because it has been open for 3 months with no activity.

@github-actions github-actions bot added the stale label Oct 1, 2023
@pinkfloydx33
Copy link

Came here looking for the same thing. Our unit test runs are taking an incredible amount of time and we want to look into parallelizing the test run by slicing tests onto multiple azure devops agents. The problem we will have is that we still need to merge the final report. It would be ideal if coverlet offered a standalone feature that could merge multiple json reports so I don't need to bring report generator into the mix. Has there been any movement here?

@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Apr 11, 2024

If you use cobertura format instead of json this tool could help meanwhile https://learn.microsoft.com/en-us/dotnet/core/additional-tools/dotnet-coverage#merge-code-coverage-reports cc: @jakubch1

@github-actions github-actions bot removed the stale label Apr 14, 2024
Copy link

This issue is stale because it has been open for 3 months with no activity.

@github-actions github-actions bot added the stale label Jul 14, 2024
@Bertk Bertk added the Priority:3 Nice to have label Sep 14, 2024
@Bertk
Copy link
Collaborator

Bertk commented Sep 14, 2024

https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/VSTestIntegration.md#coverlet-options-supported-by-vstest-integration

Tip

Some alternative solutions to merge coverage files

  • use dotnet-coverage tool and merge multiple coverage files

    dotnet-coverage merge artifacts/coverage/**/coverage.cobertura.xml -f cobertura -o artifacts/coverage/coverage.xml*

  • use dotnet-reportgenerator-globaltool to create a HTML report and a merged coverage file

    reportgenerator -reports:"**/*.cobertura.xml" -targetdir:"artifacts\reports.cobertura" -reporttypes:"HtmlInline_AzurePipelines_Dark;Cobertura"

@github-actions github-actions bot removed the stale label Feb 23, 2025
@github-actions github-actions bot added the stale label Apr 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature request Priority:3 Nice to have stale
Projects
None yet
Development

No branches or pull requests

6 participants