Im working with the team which develops sonarqube plugin for gosu language. This plugin is written in java. For merge requests our pipeline installs new version of plugin, runs scans against our sets of code sources, results are not commited to database (preview mode) but exported and then we compare those exports whether the change from merge requests introduces any regressions or not.
When change is merged, another scans are performed but this time without preview mode (to create newer version of “reference” reports)
Currently Ive got the task to migrate the infrastructure to newest version with sonarqube 9.6 where there is no “preview mode”. I thought that we could somehow create docker image from which containers would be created for each MR and load postgress database “reference” dumps on start. Then, after scan and reports export, such container would die and commited changes would die with it. Ive tested this solution locally and theoretically it works ok. But database dump is big (1,6GB). So downloading it, seeding and sonarqube start takes ~5-6mins.
So is there a better way to do this? Is there any alternative for “preview mode”?
First, I don’t understand why you would migrate to 9.6. It’s EOL. Migrate to at least 9.9.
Second, it sounds like you really need to upgrade your edition as well to Developer Edition($), which includes PR analysis. That’s your preview mode.
Hi @ganncamp
Preview mode is something I was looking for too and was disappointed to see it used to exist and has been removed (as opposed to never existing at all so a potential future feature).
The use case here is where there are projects which have a lot of unit tests and take a long time to run in CI and therefore a long time before an engineer will see the PR analysis results.
They want to be able to run the sonar CLI locally + in this case pylint analysis (though could apply to any local tooling) and see how that looks so they can fix issues more quickly without wating for the approx 1 hour turnaround for a build.
Please step over the fact that a unit test ci build is taking that long (it is a LOT of tests) and please don’t mention SonarLint - the engineers basically want to run pylint locally + sonar without publishing to the remote instance.
preview mode seemed perfect for that…and I guess SonarLint is essentially doing something similar somehow.
Is there any way for engineers to run analyses without publishing?
So…how does SonarLint mange to do it then - is there some hidden setting?
It wouldn’t cut it in this case a) because the engineers want a command line tool but moreso I guess b) because they want to pull in linting results and get a quick idea if their code quality is good.
Yes you can have IDE plugins for linting tools but that doesn’t help with point a) and also means you don’t have a “single source of truth” - ie the SonarQube analysis - for all of the issues,
I do recognise that this is imperfect - if nothing else because it does not include code coverage - but we live in an imperfect world and sometimes have to try to accomodate the wishes of engineers in their real world day to day scenarios
There’s a lot here & some of your points intertwine IMO, so forgive me if this gets confused…
Even more than they want to stay in-context in the IDE? I would expect a CLI to be a second-best, at best.
Okay… SonarQube is the single source of truth.
SonarLint is a first line of defense - the first few, actually. By default it’s going to tell you what pops up in your code as you type. That’s the first line. Second line (in SonarLint for IntelliJ/JetBrains): there’s a pre-commit view where you can see all the issues in the files you’ve changed, before you commit them.
That’s explicitly designed to help developers “get a quick idea if their code quality is good.”
This is probably the most important question…the one you didn’t answer
Even more than they want to stay in-context in the IDE? I would expect a CLI to be a second-best, at
Sometimes neither my expectations nor yours are more important than what the engineers want - we can guide and advise them, but if they really want to work a different way then we should try to accomodate that IMO
SonarLint is a first line of defense
SonarLint does not always align with the results you would get in SonarQube, comes with it’s own bugs and, in the Visual Studio version at least still does not let you see only the “PR” view - which renders it useless for large mature codebases with lots of existing issues.
Worse still, in v7 support for mono repo/shared code scenarios was basically taken away so it is agan rendered pretty useless for organisations working with same.
And even if it worked, it does not present a “single” view of sonar issues + linting issues or other analyses you might run locally.
Again, I recognise that a CLI solution is far from perfect - as indeed is Sonar Lint.
I am trying to understand if there is a way to support our Engineer’s preferred CLI solution with a “preview” mode - like you used to offer with an analysis parameter and which SonarLint seems to be able to magically achieve…
I guess I skipped that because I don’t understand the question…?
You used to have an analysis flag that let you run an analysis locally without submitting it to the Sonar Server and thus updating the project there
You don’t have that flag anymore
But somehow SonarLint manages to run analyses locally without updating the project in the Sonar Server
So how does it manage to do that? Is there some hidden/undocumented setting that SonarLint uses in order to run an analysis without submitting it to the server?
There is no hidden flag. SonarLint doesn’t run the scanner, it is the scanner (in a specialized way). SonarLint performs the scanner duties of finding the files to analyze (the one being edited), executing the correct underlying analysis library for the file’s language, and reporting the issues back to the user.
