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.
Related
We have a SonarQube server that is actively used by several other teams in the company, but which my team hasn't been using for several years.
When I tried to encourage my team to start monitoring code quality with Sonar again, I discovered that the Project in Sonar is being updated on a regular basis.
However, no-one in the team has any idea where these updates are coming from!
Sonar is not included in our main project POM file (we use Maven), and as far as I can tell, it's not being triggered by Jenkins (the Sonar plugin for Jenkins does not appear to be installed or configured).
That leaves a scheduled execution of a SonarScanner as the most likely source for these updates. However, in a company with several hundred servers and thousands of users, I have no idea where to start looking for this scheduled job!
Is there anything in the Sonar logs that would point to the source of the update, or anything I can configure so that this kind of information is logged?
Your best bet is to monitor to access log of the SonarQube server.
It's in logs/access.log of a SonarQube installation.
It includes the IP address and timestamp of requests,
as well as the project key when a scanner pushes analysis results to the server.
It should be easy to identify the origin of any scan.
My current TeamCity setup has several agents with pretty much the same configuration and all of them are also eligible for running the builds. However, I have noticed that TeamCity keeps scheduling runs on the same agent in a roll, even if the build fail. Actually, it happens only when it fails. Is this a known behaviour or a bug? Is there any way to change such configuration?
Check your "Agent Requirements" in the build conf according to https://confluence.jetbrains.com/display/TCD8/Agent+Requirements
I am trying to run SonarQube using Sonar runner in local dev box for pre-commit check. We have a central SonarQube server where a analysis is done every day and published to the dashboard. When we are running on local dev box everytime the the issue report contains all the issues as new hence incremental data is not available. I have also tried both incremental and preview mode but the result is some.
Please find below the version of the tools used.And also configuration files. Please let me know if some other data is required.
SonarQube version : 5.1
Sonar Runner version : 2.4
sonar-runner.properties
sonar.host.url=http://[central sonar server]:9000/
sonar.issuesReport.html.enable=true
sonar.login=admin
sonar.password=admin
sonar-project.properties
sonar.projectKey=myProj:myProj-master
sonar.projectName=MASTER_PROJECT
sonar.projectVersion=21.0
sonar.sources=./src
sonar.binaries=./bin/
sonar.issuesReport.html.enable=true
sonar.exclusions=com/**/test/*.java
sonar.skipPackageDesign=true
sonar.profile=SonarWay
sonar.preview.excludePlugins=devcockpit,buildstability,pdfreport,report,buildbreaker,views,jira,issueassign,scmstats
Command Used :
c:\sonar-runner-dist-2.4\sonar-runner-2.4\bin\sonar-runner -e -Dsonar.analysis.mode=preview -Dsonar.issuesReport.console.enable=true -Dsonar.issuesReport.html.enable=true
Updated with additional properties tried as well. in sonar-runner.properties
I believe your problem is tied directly to your use of a local server.
The purpose of preview analysis is to allow you to compare your local changes with what's on the remote SonarQube server. Since your remote server is update every night, running your preview against it will show you the issues you've introduced that day. Instead, you're running against a local instance which gets updated with a full analysis... never? Which (if true) would be why all your issues show up as new.
To execute a preview analysis against your remote server, you will need both the global Execute Preview Analysis permission and the project-level Browse permission for the project in question.
If for some reason you're unable to get those permissions (which is possibly why you're running a local SonarQube server?) Then you'll want to do the same full checkout and analysis locally every night that's being done for the official, remote server. I.e. you'll probably have to set up a second, parallel architecture. In short, it's probably easier in the long run to nag to get the appropriate permissions on the remote server.
Issue is resolved . 2 things fixed the issue.
Creating a user with the required permissions.
Installing "Issues Report" plugin
When parallel SonarQube analyses are started, all but one will be rejected / fail with error: The project is already being analysed.
I learned on this mailing list entry that it is possible to override this check by adding --define sonar.forceAnalysis=true to my Apache Maven command.
Thus (to repeat the title): Is it always safe to define sonar.forceAnalysis=true for SonarQube analysis?
Why do I care / ask?
I would like to know about any interesting corner cases or concerns about using this flag. Examples: Are there downsides or risks? Could I corrupt my SonarQube database?
I have a TeamCity cloud with multiple build agents. If more than one agent triggers a build (after multiple, successive version control commits), some SonarQube analyses may overlap.
This property is deprecated since SonarQube 3.5 and no longer necessary. See http://docs.sonarqube.org/display/SONAR/Frequently+Asked+Questions#FrequentlyAskedQuestions-Failedtoanalyseaprojectasanotheranalysisonthesameprojectseemstoberunningatthesametime(SonarQube3.4only)
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!!!