deprecation of preview mode

[andreas...@gmail.com]

Hi,

as I erroneously hijacked an existing thread for that (for which I apologize deeply), I was advised to open a new one.

I was wondering what are the plans and ideas behind the deprecation of the sonar.analysis.mode parameter is. What are the reasons ? And is there an alternative or is this going to be simply dying ?

Thanks for any answer - this is appreciated 

[G. Ann Campbell]

Hi,

The analysis mode parameter is deprecated because it has been replaced by the branch analysis functionality provided in Developer Edition($). 

Yes, Developer Edition is commercial/paid, but to be honest, that's only a small part of the motivation (if it were about money grubbing, a lot less would be included in Community Edition :-D). We've done some serious enhancements in the last couple years to our ability to find and report bugs. But being able to understand the report of a subtle NPE issue, for instance, requires more context than you can easily get from a text report. You're really better served by seeing these things in the SonarQube UI. Which means you have to submit the analysis to SonarQube. Which means not using preview mode. 

HTH,

Ann

P.S. The standard courtesies (Hi, Thanks, ...) are appreciated in this group.

[andreas...@gmail.com]

Hi Ann,

thanks for your answer :)

[chat...@gmail.com]

Hi Ann 

 

Probably I can explain the justification to keep preview mode and the importance of that in the life of a developer - 

 

While the whole world is shifting left in devOps, developer would like to get notified on the bugs early on in development lifecyle (i.e. preview mode / issues in GitHub) rather than seeing the bugs as part of branch analysis on SonarQube server.  This has 2 disadvantages - 

1. Developer needs to switch the tool (from Github to SonarQube) to see the outcome

2. The issues will be seen by other team members as part of SonarQube project, ideally developers would like to fix the bugs early on before the final result is published on SonarQuber server.

 

Would like to know your thoughts on this ?

[nicolas...@sonarsource.com]

developer would like to get notified on the bugs early on in development lifecyle

High-five to that ! That's why SonarLint is available (and continuously improving), to help developers fix issues before they exist !

Nicolas

[Raphaël Ducom]

Hi,

- What are the plans for open-source projects using sonarcloud.io ? You'll release the branch feature for free ?
- As developers, we just rarely (somes never) go on our internal sonar dashboard, all the workflow is concentrated on github PRs. As I understand, if we want to keep this workflow on a private sonarqube 7+ instance, we have to switch to paid edition ?
- We can't use SonarLint on our solutions, because of performance issues. It multiplies build times by a factor 2, that's not suitable local builds, that's why all our devs user the preview mode : delegating this heavy task to a remote build slave.

I'm really happy seeing your business model evolving, but all things being relative, 3k€ per year just for accessing to the PR reporting feature is IMO too expensive.
I really hope you'll provide another way for "simple" PR analysis, another pricing model, or at least, keep the existing open-source feature...

Thanks in advance for your answers

Bests,

[clark...@gmail.com]

Hi, 

I also am concerned about the end of life of this preview mode. Sonarlint is only available in connected mode to a very limited number of IDEs.

Github integration is also an important piece I really hope won't be broken with that change.

regards,

Gabriel.

[G. Ann Campbell]

Hi all,

In addition to Nico's point about SonarLint, I'd like to point out that we're still working on fleshing out branch analysis. @chaturya7, would you feel better if I told you that 7.1 (ETA soon) should include treating PRs as first class citizens (co-equal with short-lived branches) in SonarQube and PR decoration on the GitHub side?

Here's an example

* in SQ: https://next.sonarqube.com/sonarqube/project/issues?id=org.sonarsource.sonarqube%3Asonarqube&pullRequest=3010&resolved=false

* in GitHub: https://github.com/SonarSource/sonarqube/pull/3010

I'm going to add screenshots of those links for posterity

* in SQ:

* in GitHub:

Regarding OSS projects on SonarCloud, branch analysis is already available:

You just need to set it up.

HTH,

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/4bzwxkqJGAc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/214b7946-c93a-4cec-b808-0620d73b36c3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[naveen...@gmail.com]

Hi Ann

Thanks for your prompt reply to Chaturya's message, I will agree to both Raphael and Gabriel about the importance of having PR scan results, doesn't matter to developers on posting results on SonarQube server.  I think preview mode shouldn't be EOL considering if you are planning to have PR results in GitHub in 7.1.

Also, not necessarily, every org SonarQube upgrade is aligned with your product upgrade, few orgs may not be on 6.7 yet or planning to move to 6.7.  Moving to 6.7 will make users lose an important functionality of preview mode in PR scan (considering 7.1 is not GA'ed at this point of time)

Regards

Naveen 

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.

[G. Ann Campbell]

Hi Naveen,

Once again, preview mode is deprecated, not dropped.

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4c2e1d00-d7a7-4079-ae3c-f478e811478b%40googlegroups.com.

[ch...@romack.com]

The only problem with that statement is that developers don't always fix the issue.  

Thus the need to enforce the rules via tooling.  e.g.

1) mvn sonar:sonar should break the build if new issues are introduced

2) GitHub checks that evaluate the PR and note issue that must be resolved before the code can be merged (and BTW, disable the merge button)

Neither of the 2 above can be accomplished without some sort of preview mode.  I surely don't want to pollute SonarQube ui with activity from every pr that is created.

[G. Ann Campbell]

On Wed, Apr 4, 2018 at 12:57 PM, <ch...@romack.com> wrote:

<snip> I surely don't want to pollute SonarQube ui with activity from every pr that is created.

Why not? That's what we're doing

 

[Raphaël DUCOM]

Going back and forth between Sonar and the development context is not a realist option for most developers workflow.

At sonar, you know it, because you've create SonarLint to address this issue.

Unfortunately, SonarLint isn't suitable for large projects : it multiplies by 2 the time needed to compile a project (at least for C#)

Sure it's possible to have and use the long-live/short-live branch feature - which isn't free at all - but the current preview mode can't be replaced by this feature.

Preview mode and branch feature, are really 2 distinct functional worlds. Even if you deprecate preview mode in favor of a sub-feature of the branch analysis.

If deprecating the preview mode means this mode isn't going to be replaced by a free/open-source equivalent option, there's something wrong.
I've never seen an (semi) open-source projects restricting/deprecating open-source features, and replacing them by paid features.

It's always the other way : open-sourcing general features, and improving / innovating advanced new paid features.

Usually, deprecating means "will be deleted in the future", that's why this discussion is really important for the community

Bests,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CAEi9rULLUS0H7RfGCRH5QLbrdgEQyMjfy8B2_BfAdhOKLLTkoQ%40mail.gmail.com.

[CRG]

Will the new PR feature work with Bitbucket?  I see only GitHub mentioned.

On Wednesday, April 4, 2018 at 3:00:53 PM UTC-4, Raphaël Ducom wrote:

Going back and forth between Sonar and the development context is not a realist option for most developers workflow.

At sonar, you know it, because you've create SonarLint to address this issue.

Unfortunately, SonarLint isn't suitable for large projects : it multiplies by 2 the time needed to compile a project (at least for C#)

Sure it's possible to have and use the long-live/short-live branch feature - which isn't free at all - but the current preview mode can't be replaced by this feature.

Preview mode and branch feature, are really 2 distinct functional worlds. Even if you deprecate preview mode in favor of a sub-feature of the branch analysis.

If deprecating the preview mode means this mode isn't going to be replaced by a free/open-source equivalent option, there's something wrong.
I've never seen an (semi) open-source projects restricting/deprecating open-source features, and replacing them by paid features.

It's always the other way : open-sourcing general features, and improving / innovating advanced new paid features.

Usually, deprecating means "will be deleted in the future", that's why this discussion is really important for the community

Bests,

2018-04-04 20:12 GMT+02:00 G. Ann Campbell <ann.ca...@sonarsource.com>:

On Wed, Apr 4, 2018 at 12:57 PM, <ch...@romack.com> wrote:

<snip> I surely don't want to pollute SonarQube ui with activity from every pr that is created.

Why not? That's what we're doing

 

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

[G. Ann Campbell]

Hi,

We'll get there. GitHub Enterprise is just the first target.

Ann

You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/4bzwxkqJGAc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/80cc0a99-945c-49d6-abf7-45b0d47abbd3%40googlegroups.com.

[CRG]

I hope the preview mode won't be removed anytime soon, as we are using Bitbucket, PRs, and build breaking when sonarqube finds problems.  Our whole workflow is based on this.  We use the stash plugin to report the sonar issues on the PR itself.  It's very convenient.  I can see everything with one click of the PR link in the Bitbucket PR email.

[AngryWolf]

Hi,

I would like to emphasize that:

• Feedback for the developer as early as possible should not mean comments in the BitBucket PR. That is not early enough (can disrupt readability of PRs, and makes the impression the author was negligent), and should be the last resort in case a developer makes a mistake.
• SonarLint is a nice idea, but should remain just a convenience tool for the IDEs. There are problems with SonarLint:
• It is a separate software, thus it is prone to behaving differently to the preview mode. E.g. no TypeScript support right now.
• You don't always use an IDE. Sometimes you just execute your build process on the command line. And when I do, I expect that I also see the reason why it failed, rather than having to re-execute the whole scan in the IDE, which is slow. See TSLint for example. The IDEs just wrap the (otherwise command-line) tool.
  

So I really don't understand why things are going where they do:

• The context of an NPE-related issue is far less important to me, than having the slightest clue why the preview failed. Yes, it is useful information to see the context, but not seeing anything at all is even worse. (And even if I need the context, I can check that issue alone in the IDE more deeply.)
  
• Not providing reporting for a command-line tool feels like the community edition being a half-baked solution, a demo, that forces us to buy the real product (which is BTW too expensive), which will never be the community edition, it should really just be called a demo. A trial product with way too limited features for everyday use.
  
• The fact that the preview mode is deprecated, is equal to it eventually becoming removed. So yes, it is completely valid to start worrying.
  

And let me ask: why is really that we require a database to be able to show a full report? The preview mode already knows why the code fails. It knows just enough. And quality gates should be cheap to query from the DB, right?

In my opinion, for preview mode no result should be stored in the DB. It would be just pointless traffic load for the DB system. When I hear the word "branch," my first impression is that I'm forced to commit my changes before being able to check with Sonar! So why can't preview mode work like any other proper linter tool?

Regards,

AW