[Risk Hotspots] Break build when risk hotspot threshold is not met

[dfspinto]

Hi everyone,

I've recently integrated ReportGenerator within our pipelines and it's working perfectly.

Initially I was using the minimum coverage threshold settings to block the pipeline in case the thresholds were not met, but afterwards I moved that validation to the BuildQualityCheck as I also wanted to ensure warning-free code.

Now I've noticed that the pipeline is not blocked whenever the risk hotspot thresholds are not met. It was using the defaults, but I also added them to the custom settings just to make sure - it still does not block the pipeline, even though it shows as red in the report.

- task: reportgenerator@5
  displayName: 'Generate Coverage Report'
  inputs:
    reports: '$(Build.ArtifactStagingDirectory)/TestResults/**/coverage.cobertura.xml'
    targetdir: '$(Build.ArtifactStagingDirectory)/CodeCoverageReport'
    reporttypes: 'HtmlInline_AzurePipelines;Cobertura'
    sourcedirs: '$(Build.SourcesDirectory)'
    title: '$(Build.Repository.Name) Code Coverage'
    tag: '$(Build.BuildNumber)'
    verbosity: 'Verbose'
    classfilters: '-*.Tests;-Program;'
    filefilters: '-*Connected Services*;-*Dtos.cs'
    customSettings: |
      riskHotspotsAnalysisThresholds:metricThresholdForCrapScore=30;
      riskHotspotsAnalysisThresholds:metricThresholdForCyclomaticComplexity=15;
      riskHotspotsAnalysisThresholds:metricThresholdForNPathComplexity=200
    publishCodeCoverageResults: true

I'm wondering if ReportGenerator actually breaks the build in case the risk hotspots thresholds are not met and in that case I might be missing something in the configuration above, or it just does that on the coverage.

[danielpalme]

@dfspinto
ReportGenerator does not break the build for risk hotspots

Currently there are only options to break when one of the coverage metrics is below a threshold:
https://github.com/danielpalme/ReportGenerator/wiki/Settings#minimum-coverage-thresholds

But I think that's a good idea. I will consider this in the next release!

[danielpalme]

@dfspinto
ReportGenerator 5.4.7 now has some new settings regarding risk hotspots:
https://github.com/danielpalme/ReportGenerator/wiki/Settings#risk-hotspots

The previously existing settings specified minimum values.
Metrics exceeding the minimum are considered as risk hotspots.

The new settings are maximum thresholds.
If any risk hotspot is greater than this threshold, ReportGenerator will exit unsuccessfully.

[dfspinto]

Hi @danielpalme,

Thanks a lot for considering and releasing it pretty fast.
I've introduced the new settings and can confirm that it's working as intended.

2025-06-03T10:12:20: The risk hotspot value 24 for assembly '[redacted]' class '[redacted]' method 'Execute()' metric 'Cyclomatic complexity' is greater than the maximum threshold of 15.
2025-06-03T10:12:20:    at Palmmedia.ReportGenerator.Core.MaxiumRiskhotspotsThresholdsValidator.Validate(RiskHotspotAnalysisResult riskHotspotAnalysisResult) in /_/src/ReportGenerator.Core/MaxiumRiskhotspotsThresholdsValidator.cs:line 87
   at Palmmedia.ReportGenerator.Core.Generator.GenerateReport(IReportConfiguration reportConfiguration, Settings settings, MinimumCoverageThresholds minimumCoverageThresholds, RiskHotspotsAnalysisThresholds riskHotspotsAnalysisThresholds, ParserResult parserResult) in /_/src/ReportGenerator.Core/Generator.cs:line 349
   at Palmmedia.ReportGenerator.Core.Generator.GenerateReport(IReportConfiguration reportConfiguration, Settings settings, MinimumCoverageThresholds minimumCoverageThresholds, RiskHotspotsAnalysisThresholds riskHotspotsAnalysisThresholds) in /_/src/ReportGenerator.Core/Generator.cs:line 180
##[error]The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1

It would be perfect to propagate the info message, which describes why the generator fails, to the pipeline using ##vso[task.logissue type=error] but I believe you are not doing that anywhere and therefore is out-of-scope from this discussion.

[danielpalme]

@dfspinto

It would be perfect to propagate the info message, which describes why the generator fails, to the pipeline using ##vso[task.logissue type=error] but I believe you are not doing that anywhere and therefore is out-of-scope from this discussion.

Correct, I don't propagate messages anywhere else. Maybe I can change that in a future release.