Hi
As mentioned in this comment, the ReportGenerator task does not provide a way to push Pull Request line indicators for Azure Devops.
The repo azure-pipelines-coveragepublisher contains what's needed to understand how it's done though, as hinted in this comment.
Here, we can see that it uses something that acts like a ReportGenerator plugin to build an object that is then serialized to json (with a .csjon extension) and sent to Azure Devops.
To my understanding, this is all what's needed to get PR indicators.
Regarding ReportGenerator, we can leverage it because the PublishCodeCoverageResults@2 task also natively support cjson files. In that case, it sends the file to azure devops, does not produce any summary and does not add any artifact.
It's ideal in cases where html reports are not necessary, but PR indicators are. It speeds up the generation a lot, especially on big repos. We have repos where switching from PublishCodeCoverageResults@2 with opencover files to ReportGenerator with lcov -> cjson reduce the duration by 60x.
I've managed to build a solution that works with:
- task: ReportGenerator@5
displayName: "Generate code coverage report"
inputs:
reports: '$(Common.TestResultsDirectory)/*/coverage.info'
targetDir: '$(Common.TestResultsDirectory)/code-coverage-report'
reportTypes: 'Cjson'
riskHotSpotAssemblyFilters: '-*'
plugins: '$(Build.SourcesDirectory)/ReportGenerator.cjson.dll'
condition: succeededOrFailed()
- task: PublishCodeCoverageResults@2
displayName: Publish Code Coverage Results
inputs:
summaryFileLocation: '$(Common.TestResultsDirectory)/code-coverage-report/coverage.cjson'
condition: succeededOrFailed()
With a custom report builder that basically reproduces the behavior of GetFileCoverageInfos() in the CreateSummaryReport() method with a few non required optimizations.
So first, I'd like the repo to officially support this format. I'm willing to provide a Pull Request that adds it. Would you be ok with that?
Second, I suppose that we could get rid of PublishCodeCoverageResults@2 by publishing the cjson payload to AzDevops directly. I haven't looked at how the publishing to code coverage is done in this repo though.
In the azure-pipelines-coveragepublisher repo, it's done through Microsoft.TeamFoundation.TestClient.PublishTestResults.TestLogStore.UploadTestBuildLogAsync(). If feasible, it may be done in a second PR?
Thanks!
Hi
As mentioned in this comment, the
ReportGeneratortask does not provide a way to push Pull Request line indicators for Azure Devops.The repo azure-pipelines-coveragepublisher contains what's needed to understand how it's done though, as hinted in this comment.
Here, we can see that it uses something that acts like a ReportGenerator plugin to build an object that is then serialized to json (with a
.csjonextension) and sent to Azure Devops.To my understanding, this is all what's needed to get PR indicators.
Regarding
ReportGenerator, we can leverage it because thePublishCodeCoverageResults@2task also natively supportcjsonfiles. In that case, it sends the file to azure devops, does not produce any summary and does not add any artifact.It's ideal in cases where html reports are not necessary, but PR indicators are. It speeds up the generation a lot, especially on big repos. We have repos where switching from
PublishCodeCoverageResults@2withopencoverfiles toReportGeneratorwithlcov -> cjsonreduce the duration by 60x.I've managed to build a solution that works with:
With a custom report builder that basically reproduces the behavior of
GetFileCoverageInfos()in theCreateSummaryReport()method with a few non required optimizations.So first, I'd like the repo to officially support this format. I'm willing to provide a Pull Request that adds it. Would you be ok with that?
Second, I suppose that we could get rid of
PublishCodeCoverageResults@2by publishing thecjsonpayload to AzDevops directly. I haven't looked at how the publishing to code coverage is done in this repo though.In the
azure-pipelines-coveragepublisherrepo, it's done throughMicrosoft.TeamFoundation.TestClient.PublishTestResults.TestLogStore.UploadTestBuildLogAsync(). If feasible, it may be done in a second PR?Thanks!