Must-share information (formatted with Markdown):
SonarQube, 6.7.5.38563
Code Analyzer for Java * 5.7 (build 15470) installed
sonar-maven-plugin:3.5.0.1254
I am trying to analyze with sonar and I used to have incremental mode. But I did some reading and foundout that it was replaced with “issues”. Quite confusing but anyhow that is not what payed my attention:
[INFO] Issues mode
[WARNING] The use of the issues mode (sonar.analysis.mode=issues) is deprecated. This mode will be dropped in the future.
You recently changed it and now it is deprecated
Do you have a replacement since it is already deprecated? What shall I use instead ?
To be clear, the change was not recent. In fact it was several years ago (eons in internet-years ). The deprecation is more recent, and is a result of the branch analysis introduced with 6.7 in Developer Edition.
It seems that you are trying to replace “warm” by “green”. Lets imagine, for example, scenario with Gerrit integration - even if I have the “developer edition”, I definitely don’t want to see each branch, created by the Gerrit during the review cycle, in the SQ’s db. And analysis results for such branches are never checked from SQ UI - always only from the Gerrit.
So @ganncamp, will there be a replacement for issues mode before it gets removed?
You don’t want to tell me the paid branches feature is the replacement, do you?
Besides that it is a paid feature, it has not much to do with the issues analysis mode imho.
We use the issues analysis mode with the SonarQube Community plugin to be able to locally analyse code and show found issues / new issues without the need for a full SonarQube analysis which needs about two hours.
And please don’t again recommend the SonarLint plugin, as long as it does not do the same analysis (3rd party scanners like PMD, Checkstyle, SpotBugs for example, using the respective IDE plugins is not really a viable option, as the configuration for those tools is done in the SQ web interface and cannot used by the respective IDE plugins unless you export them accordingly and check them into VCS, making sure to keeping them up-to-date manually if you change anything in the rules, this is not really a good solution).
Issues mode / preview mode / “local” analysis will indeed be removed. That’s should happen in 7.7. We feel the current, non-deprecated parts of the ecosystem provide a better overall experience.
needing to commit and create a branch that then has to undergo a full analysis that needs two hours when you usually do not work PR style, but all on the same master branch directly and then having to search for your changes in the web UI
is a better experience
than just telling your IDE to analyze the 3 files you changed locally and show the new issues before you even think about committing?
I mean, I’d have probably no concerns if the SonarLint analysis would be the same as the normal analysis, but unless it supports the 3rd party tool integrations like Checkstyle, PMD, or SpotBugs, this is not the case.
Yet with that you loose the possibility to configure which rules you want applied and which not via the SQ UI, don’t you?
I think it is quite convenient that you can manage all rules at one central place.
We think so too, actually. But I think what we were hearing from users was that they were already managing their TSLint configurations, for instance, just fine outside of SonarQube & they didn’t want to have to re-configure inside SQ. In fact, it has been a number of years, but I can remember hearing exactly that same complaint from Checkstyle (or was it PMD?) users.
So… I recognize that at this point the message is a bit incoherent: use SonarLint but only for some analyzers; configuring all rules in one place is best but we don’t support that for SL integration.
And… that’s all I got, except to say we’re evolving on these (and most other!) topics.
BTW, just for the record, the reason we don’t support non-SonarSource analyzers in SonarLint is to make sure we can give you a good user experience in SL all the time, every time. For instance, about once every two months or so, we get a fresh complaint in the community related to the fact that if you have the FindBugs plugin onboard, it’s going to run - and use up possibly significant analysis time - whether or not you have any FB rules enabled in your profile. This performance impact is just one example of the kinds of thinks we don’t want to expose ourselves and our users to through SonarLint.
Well, maybe it would be better to fix SpotBugs then.
The problem is, that it always does a full analysis and only filters the issues afterwards with the config SQ generated, so the analysis will always need its time yes.
I surely see the point about the user experience.
Actually I think it is worse user-experience that you see different results when running through SL than through the normal SQ analysis, but well, it seems you have a fixed opinion regarding that, and that’s ok, just sad.
SQ and SL are different products, that run in different environments. For instance, SQ can run rules that analyze a whole project to find security issues. This process can takes some time, and requires to have the whole project available for analysis, which are two things that may not be readily available in SL.
It looks natural to me to work on different subsets of rules in those products, as long as the rules present in both subsets produce the same results when run on the same code.
Ann, you should know that in-IDE checking doesn’t work for some languages. Take PL/SQL as and example: many companies use Oracle SQL Developer or PL/SQL Developer (from Allround Automations). They can be extended with plugins, but there is no definition of “project” in PL/SQL (as in Maven, Ant, MSBuild…). Many times it’s just a bunch of scripts that can be organized and executed together. Even if someone develop a SonarLint plugin for these IDEs, I can’t see how one would implement the SonarLint connected mode. And don’t tell me “you can use SonarPLSQL in SonarLint for Eclipse”, because Eclipse is not a good IDE to write PL/SQL code.
Sometimes the IDE is not extensible at all, see Oracle Forms Builder. To do a pre-commit check, the only option is to use the preview mode of sonar-scanner.
We have a big PL/SQL project in SonarQube, the sonar-scanner takes ~3 minutes to run a complete analysis and we have to wait more ~4 minutes to see the results on SonarQube dashboard. For this situation, we developed an internal tool to run sonar-scanner with sonar.analysis.mode=issues and process the .json output. With this tool the developer can run an analysis on a single file and see if there are any new issue.
You say:
But I can’t see how having to wait for 7-8 minutes for a branch analysis in SonarQube is a “better overall experience” than executing a local scan with sonar-scanner in 10 seconds. The short-lived SonarLint CLI looked like a good alternative, but you deprecated it too. Being forced to use branches for this scenario is a big “no” for us.
Thanks @ganncamp. I could describe how hard it would be to use SonarLint in Eclipse, but it seems that you won’t change your minds about this. So I won’t spend my time. It’s your product, and of course you can do whatever you want. I understand that my usage is very specific and you don’t want to support it, but that’s ok. I’ll see what we can do about it.
Edit: after re-reading my answer I think I sounded too harsh. If this is the case, I apologize. I’m not a native speaker and I’m not sure how to rewrite this. Don’t take it personally, please.
One additional question to the exported external reports.
For this would one still have the respective sonar plugins installed, or not?
I guess the respective plugins should then not be installed.
But how does SQ then know about the rules and descriptions to display for findings?
Assuming the answer is yes, you don’t have to have those plugins installed; selected tools’ reports are natively supported by our analyzers. For deeper questions about the details of rule descriptions &etc. it would be best to open a new thread.
I have just noticed the deprecation message in our builds as well, and honestly, this feels like a bit of a backstab.
If branch analysis was a paid feature from the beginning, we would look for an alternative product. But after people invested time into incorporating sonar into processes for checking code in feature branches, it’s suddenly being dropped entirely and replaced with a paid feature? I know that you have to make money somehow, but this feels a bit like a hostage situation.
Not to mention that the multibranch feature that is supposed to replace this is unnecessarily bulky for our purposes - we just need the sonar analysis to mark a GitLab merge request as failed if there are any issues (and I’m not even sure if this would work with normal analysis as opposed to issues mode).
