We use cpp-check and SonarQube 6.0 and want to inject the results of cppcheck into the system. Cppcheck runs fine and produces an xml-file with results. However Cpp-check and SonarQube are not running on the same machine.
Is it sufficient to set something in
Administration > C++(Community) > CodeCode analysis > Cppcheckreports ?
We put the name of the xml into that field - but how should SonarQube find that?
What are we missing here?
The cppcheck plugin for SonarQube has not been maintained for 6 years now and won't work with resent versions of SonarQube. https://github.com/SonarQubeCommunity/sonar-cppcheck/issues/6#issuecomment-377563241
SonarQube and Cppcheck don't have to run on the same machine. But the Cppcheck report does need to be available to the analysis. If you can't run analysis on the machine where Cppcheck runs, then you just need to set up some process (FTP? Sneakernet?) to get the file where it needs to go.
This all assumes you have the Cppcheck plugin installed in SonarQube, as well as some plugin, such as SonarC++($), which declares the language.
Related
Installed clean windows10(1607) and intellij idea(2020.1.2 community edition). When i create new gradle project
Invalid Gradle JDK configuration found. Open Gradle Settings
"gradle-wrapper.properties not found".
How can I fix it?
Install gradle 6.7
sdk install gradle 6.7
brew install gradle
Go to IntelliJ and set gradle version:
On File >> Settings >> Build, Execution , Deployment >> Gradle
or
Preferences >> Gradle
In Use Gradke from specific the correct location
If IDEA is set to use the Gradle wrapper (as it is in your screenshot: "Use Gradle from:" is set to "gradle-wrapper.properties"), IDEA expects the following file structure:
Gradle wrapper JAR: [project root]/gradle/wrapper/gradle-wrapper.jar
Gradle wrapper properties: [project root]/gradle/wrapper/gradle-wrapper.properties
Gradle wrapper script: [project root]/gradlew.bat
If you are missing one of these three elements, IDEA will attempt to generate the wrapper by calling the gradle wrapper task. It will do this using the Gradle JDK, which may or may not be the project SDK (File > Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JVM).
I'm not sure how it selects the version of Gradle it uses - I only have 6.8.3 installed on my machine, and I had my wrapper properties set to 7.0-rc-1, yet somehow it used 6.7.0 when generating the wrapper.
I tried various options for clearing the cache, but did not get the result.
Openjdk-14 installed by default and does not work. From site adoptopenjdk.net install OpenJDK 11 (LTS). When creating the project, I chose 11 version. Then the program suggested updating gradle to version 6 and it worked.
I ran into this problem a while ago when I upgraded to intellij 2020.* The first time I created a new project there was no problem: gradle daemon did its work and the project was created with no problems.
In my case, the project would start a new gradle daemon, and attempt to build the project, would get rejected by windows Security, and nothing would happen, so intellij goes ahead and starts another (unsuccessful) daemon. Soon, I had 20+ gradle daemon processes running on my system, all of them doing nothing.
So, it looks like intellij has messed in enabling that it places the appropriate permissions it requires for these folders that it depends on to run properly. So, you need to manually give these permissions, and then things (should) work.
The real issue here is security on your machine: either a virus checker or the security software, Windows Security on Windows 10, for example. The first time you make a project, Intellij goes and produces a number of folders that they need access to.
However, once these folders are available, for whatever, intellij doesn't make sure to give itself access.
On windows 10, in AppData, you'll find several folders required by Intellij to produce, in my case, produce gradle projects.
Try finding the various folders that Intellij has produced on your system, and give them exceptions on your virus checker and on whatever firewall/security software programs that may block access.
Local build generates reports in the correct folder: target/results
but when building using Jenkins it puts them in target/gatling/results
This is an issue because now the gatling plugin for Jenkins is unable to find the reports
I can't find where it sets the path
It is not necessary to configure the results folder path for the gatling plugin for Jenkins. It will look for any folder containing a Gatling Simulation, so your configuration doesn't matter.
If you can't make it work and think it is a bug, provide us your jenkins version, gatling-plugin version and gatling version.
You can use our mailing list to post questions specific to Galing.
I am runnig Sonarqube 5.3 and has integrated it with Jenkins. I want to post Sonareqube issues as Gerrit comments.
Then I need to specify the path to and name of the data generated from sonarqube, e.g. build/sonar/sonar-report.json
The file sonar-report.json is not generated and I have found some setting for Sonarqube that shouold make sonareqube create the file.
sonar.report.export.path=sonar-report.json
sonar.issuesReport.html.enable=true
sonar.issuesReport.json.enable=true
sonar.issuesReport.console.enable=true
I have tried to set these in the file
<sonar-installation-directory>/conf/sonar.properties
I have restarted the Sonare service and restarted the computer but the sonar-report.json file is still not created.
Those properties are not meant to be configured on the server side, they are passed on the scanner side, and are valid only for analysis in preview mode (by the way no need for sonar.issuesReport.json.enable). That's what SonarLint for Command Line is about.
Why preview mode ? Because the goal is to analyse a diff (to comment the code review in your case). You don't want a full analysis to be submitted to SonarQube if the code is not yet pushed to the repo.
Example:
$ sonar-runner -Dsonar.analysis.mode=preview -Dsonar.issuesReport.html.enable=true -Dsonar.report.export.path=report.json -Dsonar.host.url=http://localhost:9000
[...]
$ ls .sonar/
issues-report report.json
(careful with the JSON report, looks like it will ultimately be removed, see SONAR-7247)
P.S.: I guess you might be using the sonar-gerrit Jenkins plugin, which is essentially saying the same thing:
This plugin is intended to work with report provided by SonarQube running on your project in preview mode
Maybe, this question is silly but I'm very new. I try to search without luck.
I got two errors when building maven project with sonar:
No information about coverage per test.
Although I had test code and these testing classes cover the code.
The global property 'sonar.doxygen.deploymentPath' is not set. Set it in SONAR and run another analysis.
I dont know it should be set where in sonar server. I set in web.xml or sonar-server.properties but it does not work.
Thanks.
About the first warning message this is not an error but a warning : since Sonar 3.5 this is possible to get the code coverage relating to each unit test. Here the message just says that this feature is not activated which is expected by default. Nevertheless I do agree that this warning message can be misleading.
About the second error message, I don't know the doxygen plugin but the message seems to be pretty clear : the sonar.doxygen.deploymentPath property has not be defined. See the plugin documentation : http://docs.codehaus.org/display/SONAR/Doxygen+Plugin.
Two things:
There is no war folder anymore since the sonarqube has given up tomcat support
The doxygen plugin is not implemented to upload the files in to the sonarqube server &/ installation, which means it only can be done by referencing the path inside your installation, e.g.:
run "mvn install sonar:sonar" in your project "/root/test.example.sonar.com"
in sonarqube set the cfg-key "sonar.doxygen.deploymentPath" the value: "/root/sonarqube-4.1.1/web/" and the cfg-key "sonar.doxygen.deploymentUrl" the value: "http://:9000"
have fun with your doxygen
Remember that the plugin will only be run through your mvn cmd, refreshing the page only will not do the job, you will have to analyse again after each cfg set :/
Check the file system and folder permission
I'm setting up Jenkins for the first time and running into an issue where Jenkins does not appear to even attempt to execute the Ant task I've specified.
I've defined my JDK and Ant installations under Manage Jenkins.
I've setup my Job to Invoke Ant using the Targets 'war-all'
Whether I force a build or wait for it to naturally execute after the next commit, there is nothing in the Build Console Output about attempting to execute the ant task.
Here is a sample Console Output:
Any ideas as to why it might not be executing would be appreciated. Also tips on how I can find more logging from Jenkins which might provide clues as to why it is not executing would be helpful. I'm not sure what Logger I might specify or even then where the logging information is written on the file system.
The problem was that I was selecting "Build multi-configuration project" as the type of my job. When I select "Build a free-style software project" as my job type the Ant task will execute after the SVN update.
Looks like your svn doesn't see any changes and therefor is not re-building the module.
Try deleting the workspace and re-trigger the build, or change the check-out strategy to 'Always check out a fresh copy'.
I faced the same problem when upgraded to 1.417 from 1.413.
The combobox "Ant version" disappeared from "Invoke ant" build step. It should be here.
I just downgraded to 1.413 and continue to work.
So, the answer is - you should specify "Ant version" in project settings. But you cannot do it in 1.417.
It seems like Jenkins doesn't like when you create a job before configuring JDK. If that happens, job will never work properly. So, for me the solution was:
Delete job.
Configure JDK
Re-create job.
Probably the same problem may arise when job's JDK is deleted.
In my case,ant default target was not being picked up from build.xml so I had to explicitly mention the target in jenkins option.
I resolved this by changing the jdk to default and then again switched to what was set earlier.This is a workaround but not sure how this resolved.