Pull request decoration should not require the developer edition

sonarqube
vsts

(Michael Petito) #1

PR decoration support was available in the community edition of Sonarqube v6.x. However, since v7.x PR support is now tied to a branch analysis feature that is only available in the developer edition.

I don’t need to view long-lived branches and filter issues by branch in Sonarqube, so as far as I can tell I do not need branch analysis. In fact very rarely do I want to go into Sonarqube at all. What I’d like to do is get PR decoration from Sonarqube to highlight new issues before they’re merged. Based on other discussions I’ve read, this desire is not unique to my team.

The 6.x functionality was supported using the “preview” analysis mode which is now deprecated. The VSTS plugin can no longer run a PR analysis in preview mode because it automatically sets the branch name and triggers the paid branch analysis feature.

PR decoration is a primary use-case for Sonarqube as PRs are used everywhere and are the primary tool for code review. My suggestion therefore is to restore the 6.x PR decoration functionality / preview mode analysis as part of the community edition.


(Nicolas Bontoux) #4

Hi @mpetito,

While I understand your ask here, I think there are a few points that are worth clarifying in order for the big picture to be clear.

Two main thoughts coming to mind. The first one is about your comparison of the (now deprecated) preview mode, versus the Pull Request analysis feature.

Functionally speaking there is quite a gap between what was possible in 6.x, and what is now offered with the full-fledged support of branches and Pull Requests. Sure the past preview mode could help get an insight into issues detected locally, however our intent with the Pull Request decoration feature is to provide a consistent experience, for example:

  • issues in synch with issues tracked in SonarQube and/or in the main branch: making sure that your PR is not polluted by issues you would have already triaged (e.g. as Won’t Fix for a specific reason), showing only issues on the lines of code which you’ve changed, automatically track issue states/comments in case you do merge an issue etc.
  • ability to deep dive a specific issue and understand its origins and how to fix it: the SonarQube UI fully renders all code locations related to your issue, so that you know how to tackle it. A picture speaks better than words.

Those are just two examples, which we believe put PR support miles aways from the experience preview mode was offering (local static report, with no integration/tracking whatsoever with the overall project state).

And to be clear: I fully appreciate what you say when referring to ‘rarely do I want to go into Sonarqube at all’, however PR support should not be taken as pure UI integration, as there’s this entire piece under the hood which now guarantees that the feedback you get in PRs is most relevant and accurate as possible (contrary to just an independent local scan).

That was my first comment (maybe a bit more verbose than I’d had expected). My second comment is much shorter! Relates to this ‘paid’ aspect:

I simply want to remind that analysis of branches and pull requests is something SonarSource offers for free to all open source projects , using SonarCloud :sonarcloud: .