SonarCloud + GitHub + Pull Request Analysis = No Inline Comments

sonarcloud
github
pull-request

(Chris Romack) #1

We are in the process of evaluating SonarCloud in comparison to our current, on-prem SonarQube and am having issues with request analysis. Specifically with inline comments.

The analysis completes successfully and the Pull Request check shows up in GitHub (with a failed status), however I do not see the inline comments. Is that a configuration option or have those gone away in SonarCloud?


Binding Existing Organisation to GitHub
(Janos Gyerik) #2

Indeed we have removed all comments from the Conversation tab. See this announcement.


(Rick Hanton) #3

@janos That seems foolish. That was one of the biggest selling-points of using SonarCloud vs other scan services when we did an analysis last year.

Can we expect the Sonar-injected comments in the Conversations tab to come back in the future?


(Janos Gyerik) #4

It seems the Conversation tab is intended for content by humans, not by robots. For that reason we don’t have plans to go back on that route. It seems Checks is the way to go for such automated checks that we do. We are considering to enrich the feature in that direction.


(Lewis O) #5

Although I appreciate that conversations are better for humans, there is already extensive precedence for robot actions being annotated in that view. Furthermore, it is of massive value to get an automated GitHub “Review” from SonarCloud, and it would be good to use GitHub’s functionality for displaying that. This seems to have been taken away.

It is extra frustrating as I had sunk some time into trying to get this work as is described in your documentation:

Pull Request analysis allows you to:

  • see your Pull Request (PR) analysis results in the SonarCloud UI and see the green or red status to highlight the existence of open issues.
  • automatically decorate your PRs with SonarCloud issues in your SCM provider’s interface.

https://sonarcloud.io/documentation/analysis/pull-request/

However, since your announcement, this is not how it works. At least please update your documentation to make this more clear.

And, please reconsider this decision.


(Fabrice Bellingard) #6

As @janos said, Checks functionality is now the way GitHub expects external integrations like SonarCloud to contribute information to a Pull Request - instead of “abusing” the comment feature to kind of “pollute” human reviews.
If you think this is not working well, I suggest that you push this feedback to GitHub forums.

Can you clarify what makes users think that the PR decoration is done through comments instead of checks? The documentation does not mention comments - so I’m a bit confused.


(Lewis O) #7

I believe this line is misleading.

  • automatically decorate your PRs with SonarCloud issues in your SCM provider’s interface.

It certainly led me to believe that the GitHub plugin operated in the previous way where each issue showed in-line with the code.

I looked into the GitHub checks feature to see if I should complain to them, but I shouldn’t as GitHub Checks already supports “Annotations” which achievs this. Their Hello World example shows this: https://developer.github.com/apps/quickstart-guides/creating-ci-tests-with-the-checks-api/#step-24-collecting-rubocop-errors

Have you migrated to GitHub annotations, or is it an error in my configuration that means I am not seeing annotations/inline decorations?


(Fabrice Bellingard) #8

I guess you might have missed the following part in PR analysis results are now displayed in the Checks tab of Pull Requests in GitHub:

As you will see, we decided for now to not display issues that are discovered in the code of the Pull Request (as well as issues that are not in the code).
The reason is that with Checks, we first wanted to use Annotations to display issues. We realised that we would not be able to display in the best way we want the issue information such as the type of the issue (bug, code smell, vulnerability), the severity of the issue and the link to the issue in SonarCloud. You can still retrieve all those information on SonarCloud, via the link.


(Lewis O) #9

Correct, I missed that.

That only makes me more disappointed that you thought about it and chose not to use it. This has quite a negative impact on our workflow.

Like with @Rick-at-KUBRA, this is a key function for us and was part of our selection criteria when we migrated from Codacy. This change puts us in a tough position.


(Fabrice Bellingard) #10

I’d like to dig into why you think this puts you in a tough position. With the quality gate summary and the links available in the SonarCloud Check page, you get the big picture of the quality of the PR and can get access (through the links) to the complete list of found issues with far more details, explanation and help than what you could get with annotations inside GitHub.


(Rick Hanton) #11

@Fabrice_Bellingard I think a simple way to explain it is that ideally you want your developers to stay in a simplistic workflow. I went to Atlassian’s talk at AWS Re:Invent 2 years ago where they explained how they thought you should use github hooks to push Jira tickets to sequential states so that a developer doesn’t need to interrupt coding to go do that in Jira as a secondary task. In my mind, this is a similar situation where if you tell a smart developers “Hey, there’s a problem in this line of code!”, they may easily identify and fix the problem without the extensive details, explanation, and help at sonarcloud.io and can then go back to work.

So ideally the plugin would use annotations in the files tab to point to where an issue is occurring AND provide some links (in the annotation or the Checks tab) to help green-er developers get further help in solving the problem.