After running SonarScanner there is now a “.sonarqube” folder in my project directory with the following structure:
.sonarqube
bin
conf
out
We have noticed that the contents of the conf and out directories seems to change with every run of SonarScanner. This is adding a lot of “noise” to our git commits that I am hoping isn’t necessary. Is it safe to add the .sonarqube folder to git ignore, or is there a reason that data would need to be shared between team members?
I find this mildly alarming. Is your CI committing build products back to the repository at the end of the job?
Because ideally that’s the only place analysis happens. If you’re going to tell me that developers run analysis locally because they need the feedback, I’ll point you to SonarLint which is a FLOSS IDE plugin available for most popular IDEs. And to pull request analysis, which is available starting in Developer Edition($).
Unfortunately we have no real CI to speak of. We work under a government contract and unfortunately while we develop the software, control of the servers and deployment pipeline fall under a different contract/company. So, when we are finished with a sprint we have to package up our solution and hand it off to another team under the other contract to actually do the deployment. We have been in talks with them for a long time to get some sort of CI setup but so far no luck because [insert a thousand political reasons here].
As for SonarLint we are trying to use that as well but finding it not to be as useful as we had hoped. We have developers on our teams that use Visual Studio, VS Code, and Jetbrains Rider as their primary editors. SonarLint is supported on each of these but unfortunately the support is very inconsistent. For example, in VS Code the language support covers JavaScript, TypeScript, and HTML but not C#. In Rider it supports C# but none of the other languages. This is making it very difficult to enforce a consistent set of rules for all of our developers.
Our process for now is to run SonarQube via command line with SonarScanner at the end of a sprint prior to submitting code for deployment as a final check to make sure there are no major issues we need to address before the deployment. Like I said this is causing a lot of files to be generated in the ‘.sonarqube’ folder and we are trying to figure out if it’s ok to just exclude them from source control, or do they need to be checked in for some reason? Thanks for the help!
Right. I never actually answered your question. You don’t need to check them in.
At the risk of being obnoxious… Even recognizing the constraints you’re under, I wonder if it wouldn’t be possible/worthwhile to set up a server in the corner with a central Jenkins & SonarQube for just your team’s use so that you know with each merge or commit that the team as a whole is on track, rather than just doing this once before hand-off? Maybe that helps. Anyway I had to try. Thanks for putting up with it.
Thanks for the answer. You are not being obnoxious, and to be honest I couldn’t agree with you more. If it were up to me we would have gotten a lot of this set up ages ago. We have been making slow steady progress though and supposedly “soon” we will have access to CI and automated builds to our dev and test environments through TFS. In the mean time we will try to do what we can with what we have, wish us luck!
