I use Sonar through the sonar runner client. Actually, I call it from NAnt build system, and the NAnt exec call should fail in case the exit code is not 0.
However, I've recently faced with an issue that sonar runner always returns 0 exit code, even if one of the plugins (e.g. NDeps) throws exception. As far as I can see, the analysis data is not committed to the database in this case, hence it is a good reason to fail.
I seem to remember that one of the previous versions of Sonar / Sonar runner used to behave the way I expected - in case a plugin fails, the exit code was not 0.
Today I use Sonar 3.2 / Sonar runner 2.0 / C# Ecosystem 1.4, which is all the latest as far as I can see.
Is there a configuration flag somewhere to return proper exit codes? Any other workaround to this issue?
For information: discussion happened on this topic is currently happening on Sonar User mailing-list. It can be followed here: http://sonar.15.n6.nabble.com/Sonar-runner-exit-code-is-always-0-tt5003433.html
EDIT: after investigation with Yan, it turns out that the Sonar BAT script behaves differently depending on the vesion of Windows that is used. Yan has suggested a way to fix this, and a ticket has been opened for next version of the Sonar Runner.
Related
Quarkus Version 2.1.2.Final
When running in quarkusDev everything is running in the correct thread (vert.x-worker-thread-x) and is even obeying the quarkus.vertx.worker-pool-size property as I would expect.
When running the quarkus-app that is built from the build task I am seeing the thread of execution as (executor-thread-x).
Not sure why the thread of execution is changing when running the application after it's been built vs running in quarkusDev. As an aside I am using the exact same properties for both the quarkusDev and running the output of the build task.
I have created a sample project that showcases the above described issue. (https://github.com/owlkaboom/quarkus-threading-question) This sample project uses 2.2.1-final since I wanted to see if this was resolved in a later release.
You will notice it "submits 500" items into an eventbus which when you run it with quarkusDev you will notice it is actually using the worker-threads correctly and obeying the pool size limits.
When you build and run via java -jar you will now notice it does not obey worker-threads and just runs on the executor-thread instead.
The above mentioned issue is not expected behavior. Opened a new GitHub issue (https://github.com/quarkusio/quarkus/issues/19911).
This is not expected behavior and once the GitHub issue has been resolved / merged this behavior should no longer be happening.
SonarC# 6.7.1 (build 4347)
SonarQube Version 6.7.1 (build 35068)
Quality Profile: Sonar way (outdated copy) because the current Sonar Way quality profile returns nothing at all.
Running the current MSBuild.SonarQube.Runner (SonarQube Scanner for MSBuild 4.0.2.892) only reports Code Smells. No vulnerabilities or bugs are being reported.
Using https://github.com/SonarSource/sonar-scanning-examples - CSharpProject to test. I've added bugs from the quality profile above into the code but they never get reported. I've tried this with other CS projects with the same results.
Are there any known issues reporting vulnerabilities/bugs for C#? Is any additional configuration required to get this information reported back to SonarQube?
This isn't a known issue, and I couldn't reproduce it using the same versions of the scanner, the C# plugin and a clean install of SonarQube 6.7.1.
Analysing the sample project reported one bug (csharpsquid:S2583, Program.cs line 9), and one code smell (csharpsquid:S1118, Program.cs line 4).
Code Smells, Bugs and Vulnerabilities are all handled the same way by the Scanner for MSBuild - they are all just Roslyn issues with different categories applied. No additional configuration is required.
I'm guessing you've migrated from an older version of SonarQube since you have an outdated SonarWay. However, that shouldn't make any difference to how issues are reported. The rules included in the default SonarWay might change between versions, but you've checked for rules you know are in the active QP.
If you haven't already, you could try installing SonarLint for VS and checking it correctly detects the bugs you've injected into the code.
Other options:
the .sonarqube\conf file will contain a ruleset file showing which rules are being executed by the scanner. Check that contains the expected rules.
the bin directory of each project will contain a XXX.RoslynCA.json file containing all of the issues that were detected during the build. Check they contains the expected issues.
check the console logs for errors or warnings. You could also increase the verbosity of the logged output by passing /d:sonar.verbose=true on the command line in the Begin step.
We have had occurrences where a SonarQube job is running for hours, appears to be hung with no ETA on its completion in our CI environment. We have used a workaround solution of not only aborting the build job, but there seems to be a secondary process executing SonarQube on the CI agent itself. I have read that specifying sonar.forceAnalysis=true should resolve the issue but this has been deprecated as of version 3.X and there is no need to use this analysis parameter. We would like to be able to proactively address this and not have to respond after a team running SonarQube notifies us of this issue. Is there some way of specifying a timeout where the process running the analysis will just terminate?
If you are looking for killing the analysis running in your CI environment after a certain time, I would suggest you look into the feature offered by your CI environment.
There is no such thing in SonarQube.
As a side note, you should have a look into the upcoming 5.2 release of SonarQube. We have cut the connection to the database from the analyzer which means the error “The project already being analyzed” can not occur any more. In addition, quite a bunch of work done by the analysis job has been moved to the server which allow it to run faster.
We have just started using Sonarqube 5.1 integrated in TFS build as described on this page http://www.sonarqube.org/announcing-sonarqube-integration-with-msbuild-and-team-build/
We have one main branch, and two development branches for the same project.
What is the recommended strategy for handling this?
I want to be able to see analyze result trends over time and also let people working in different branches able to see analyze result for the branch they are working in. As far as I can see the Sonar msbuild runner (https://github.com/SonarSource/sonar-msbuild-runner) only supports projectkey, projectname and version, but not branch key.
Any advice and suggestions will be greatly appreciated!
Indeed Wangen, I do confirm that the MSBuild Runner 0.9 doesn't yet provide a way to inject some SonarQube properties and so including the "sonar.branch" property. This limitation is going to be dropped in version 1.0 of the MSBuild Runner. Nevertheless, you must be aware that the support of branches by SonarQube is really limited because at the end in your case you're going to have 3 different projects in SonarQube and for instance flagging an issue as false-positive won't lead to flag the same issue in another branch as false-positive.
I've configured sonarqube server on my local machine to run and I committed the initial project with Analysis mode. Also, I created an ant target for the developers to run in incremental mode to view their new issues. I installed issuesReport on sonar server and using it from the ant file to generate html files.
However, when each developer syncs with svn and runs the ant target, they see violations by other developers under the new issues instead of only their issues.
I expected the sonarqube plugin only scan newly edited file by the developer, but is instead showing all the new files that are introduced by other developers.
To make it work properly I have to run an analysis mode from my machine. However this fixes the problem only for me, my colleagues still see all the violations as new.
How does SonarQube decide if an issue is new or not? If each developer has to run a full analysis every time, this would be big over head. Is there something am I missing?
Thanks in advance for your time and help.
An issue is considered "new" if it does not exist on the analysis server. If you run a full analysis on a CI server on a scheduled basis, it will feed the server with issues and reduce the risk of developers seeing other developer's issues in issues report in preview mode.
Please note, that the sonar documentation says, incremental mode is only for the developers and that too for the code they run against sonar prior to scm (SVN or GIT) commit.
See incremental section on the page: http://www.sonarqube.org/analysis-vs-preview-vs-incremental-preview-in-sonarqube/
The sonar report, when run with incremental mode, will show the developer, how much issue will be generated, if he commits the code. This way developer gets to know, what he can do to keep the sonar issues low. This is the whole purpose of incremental mode.
Hope this answers your question!!!