32

I am having trouble getting my code coverage reports to work, or rather, to get DevOps to pass my parameters correctly. If I download the build directory (zipped in the build), the ReportGenerator reports are available, but they don't get published. So I know that part is working at least. :)

However, when the publish step runs it creates new reports and uses those instead. My Yaml file is as follows:

## Generate Reports
- task: Palmmedia.reportgenerator.reportgenerator-build-release-task.reportgenerator@4
  displayName: Generate Code Coverage Reports
  inputs:
    reports: '**\coverage.cobertura.xml'
    targetdir: 'results'
    reporttypes: 'HTML;HtmlInline_AzurePipelines;Badges;Cobertura'
    assemblyfilters: '-*tests*'
    continueOnError: true


# Publish Code Coverage Reports
- task: PublishCodeCoverageResults@1
  displayName: Publish Code Coverage Results
  inputs:
    disable.coverage.autogenerate: true
    summaryFileLocation: $(Build.SourcesDirectory)\results\cobertura.xml
    reportDirectory: $(Build.SourcesDirectory)\results
    codecoverageTool: cobertura
    continueOnError: true

However, when I run in Debug, I get the following output:

##[debug]disable.coverage.autogenerate=undefined

I have tried the following options for passing this parameter:

disable.coverage.autogenerate: true
disable.coverage.autogenerate: 'true'
disable.coverage.autogenerate: 1

None of them have successfully passed anything to the task.

Without this flag set, the task overwrites the HTML reports generated by ReportGenerator and outputs the following:

##[warning]Ignoring coverage report directory with Html content as we are auto-generating Html content

I am working based upon the information pasted by Daniel Palme (author of ReportGenerator) here, as well as reading the actual code for the task here.

My source code is being open sourced, so if logs or more information help you provide an answer, it is all available here. A build with a good log is here. The Yaml file is here, and is called from the various other repositories in the project.

Any advice on how to get around this issue would be appreciated.

Martin Noreke
  • 4,066
  • 22
  • 34

2 Answers2

62

Well, in standard operating procedure, get annoyed, write a long post on Stack Overflow, find a nugget somewhere, and solve your own problem.

It is not a parameter, but rather an environment variable that needs to be set. Adding the following to the start of the Yaml file takes care of it.

variables:
  disable.coverage.autogenerate: 'true'

Leaving this here to save the next person stuck on this problem days of trouble shooting. :/

ChrisF
  • 134,786
  • 31
  • 255
  • 325
Martin Noreke
  • 4,066
  • 22
  • 34
  • I had to wait for a given time before accepting my own answer, but that was the plan once I had a solution. – Martin Noreke Jul 07 '19 at 15:54
  • 2
    Thanks this helped me out the actual Coverage reports where published into Azure Devops but when clicking on the class it didn't actually show the code with the lines. – Darren Jul 16 '19 at 16:19
  • This helped a lot. Given that DevOps isn't auto-generating a valid report for my Scala project – daz-fuller May 01 '20 at 10:08
  • FWIW, setting this variable also works around the problem in Classic Pipeline builds (i.e., non-YAML). Just set it on the pipeline's Variables screen. – Bill Menees Nov 09 '20 at 21:17
  • Also, it seems like it **does** need to be set at the job level. Adding an `env:` to the step is not enough. – David Gardiner Jul 15 '22 at 04:34
4

The following env setting accomplishes the same result as the accepted answer, but scoped only to the task.

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Build.ArtifactStagingDirectory)/testresults/**/coverage.cobertura.xml'
    pathToSources: '$(System.DefaultWorkingDirectory)'
    reportDirectory: '$(Build.ArtifactStagingDirectory)/testresults/coveragereport'
    failIfCoverageEmpty: true
  env:
    DISABLE_COVERAGE_AUTOGENERATE: 'true'
  displayName: Publish code coverage results

Edit:

I found out that the ** in the path above may cause two coverage xml files to be found, which generates a warning. Using a single asterisk may take care of it, depending on your case.

GaTechThomas
  • 5,421
  • 5
  • 43
  • 69