When I look in the SonarCloud UI for a PR, I can see the new code measurements including the “Estimated overall coverage”. This estimated value does not appear to be available as part of the webhook payload.
The closest thing I can find is the /api/measures/components. As an example, if that function is invoked for coverage for a specific PR, I get back a value like…
Most measures on overall code are not calculated for Pull Requests. You simply cannot pull metrics for bugs, because that’s a measure on overall code and the majority of those issues will be discarded in filtering the data to changed files/lines (that’s how we get to new_bugs).
coverage is a different story.
While the overall number of bugs in a project shouldn’t matter in the context of a pull request (since the focus on new code), knowing that you’ve made a change that shakes up your coverage value is pretty important (if tests didn’t run, you made some configuration change to your coverage reporter, etc.)
It should be noted that this measure will mean different things depending on how your merge is setup. Some folks have their PRs setup to merge with the target branch before running the build/analysis, and some folks build the PR branch itself. The former should indicate what coverage will actually be after the merge. The latter the coverage of the PR branch itself. That’s one of the reasons it’s Estimated (also because new code can merge into the base branch while the PR is waiting to be merged).
I’m not sure if we should be including this value in the webhook response or not, I would love to hear your thoughts.
Not quite. Coverage is a qualitative metric, but the best value would be 100%. Thus, 81.9% is not the best value. https://sonarcloud.io/api/metrics/search gives a bit more insight on which metrics are considered qualitative and which are quantiative.