How to run SonarQube for Go code using Jenkins - go

I need to run SonarQube for Go code using Jenkins. Unfortunately, there is little information regarding this task.
I have found that the "sonar-project.properties" file should be created, for example:
sonar.projectKey=com.company.projectkey1
sonar.projectName=My Project Name
sonar.sources=.
sonar.exclusions=**/*_test.go,**/vendor/**
sonar.tests=.
sonar.test.inclusions=**/*_test.go
sonar.test.exclusions=**/vendor/**
But how to configure a Jenkins pipeline correctly? I found the following example, but I'm not sure if this is what I need
node {
stage('SCM') {
git '<my_path>.git'
}
stage('SonarQube analysis') {
def scannerHome = tool 'SonarScanner 4.0';
withSonarQubeEnv('My SonarQube Server') {
sh "${scannerHome}/bin/sonar-scanner"
}
}
}

Yes, that is correct.
In your Jenkins pipeline you just need to run sonnar-scanner - that is no different from other languages (see https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/). Go language plugin comes with SonarQube so no need to install anything. Scanner will then pickup project configuration from sonar-project.properties in your project root and perform the analysis.
Your sonar-project.properties file seems like a copied example from SonarQube for Go page - you might want to do some adjustments depending on project layout (e.g. add sonar.inclusions=**/.*go). SonarQube should detect files are in Go automatically but you can also add sonar.language=go to that file to force it.
You don't mention if you run SonarQube locally or in cluster mode - but there should be little or no difference (probably adding server url and login to sonar-project.properties in case of cluster installation).
Note that go needs to be installed on scanner machines.

Related

Configure Multiple SonarQube Instances in a Gradle Build

In our CI environment, we currently have one build server (based on Atlassian Bamboo) and two SonarQube instances (versions 6.0 and 6.5). Initially, our CI server was configured to communicate with the 6.0 SonarQube instance. This has been configured in the /home/bamboo/.gradle/gradle.properties file on our CI server like this:
systemProp.sonar.host.url=<http url of SonarQube 6.0 instance>
systemProp.sonar.login=<username here>
systemProp.sonar.password=<password here>
Now we have another Gradle-based project running on our CI server which shall talk to the new SonarQube 6.5 instance. I tried configuring this but failed all the time.
Things I have done so far:
Added commandline arguments to gradle wrapper command:
I have tried adding -Dsonar.host.url=, -Dsonar.login=, -Dsonar.password= to the Gradle command. As this didn't seem to work, I have also tried to set commandline arguments as SonarQube system properties using -DsystemProp.sonar.host.url=, -DsystemProp.sonar.login=, -DsystemProp.sonar.password=. This didn't work either.
Added properties to the build.gradle file
- Added properties to the build.gradle file like this:
sonarqube {
properties {
property "sonar.host.url", "<http url of SonarQube 6.0 instance>"
property "sonar.login", "<username here>"
property "sonar.password", "<password here>"
...<other SonarQube analysis settings here>...
}
}
In all cases, the CI server talked to the wrong SonarQube instance (6.0). My question is, whether it is possible to configure a single project to talk to another SonarQube instance. As you have seen, we use Gradle 3.2.1 as a build tool. And we are using the org.sonarqube Gradle plugin too.
Thank you for any help.
André
Your first try did not work, because you set the system properties from the commandline, but setting it from the project properties later on resets the system properties to the configured values.
Your second try did not work, because the systemProp.sonar.login syntax is only suppored in gradle.properties files, not via -P commandline project properties.
Your third try did not work because the SonarQube scanner prefers the system property values over the value configured via the DSL, so that one can change what is configured in the build script with the help of local configuration.
You need to set the system properties in your build script manually, this then overwrite what was automatically set from the project property. Using the project gradle.properties file does not work as the user file overwrite the project file. So you need something like System.properties.'sonar.login' = '...' in your build script. You can either hard-code it there, or then use project properties that you can set in your gradle.properties file or via -P parameters.
Besides that, I'd never depend on having any configuration in Gradle User dir on a build server. Most buildservers use build agents that might run on distributed machines, so you would always have to make sure that all build agents are configured the same and so on. I'd always configure in the build setup of the build server the according configuration, either by setting system properties, or environment properties or commandline arguments.
Just my 2ct.

Where does Jenkins store the project source

I have a Jenkins job that uses a script to build my project. On the following line, the script fails mvn -e -X -Dgit='$git' release:prepare.
Because I want to search for the cause of this, I want to go to the Jenkins server and run mvn -e -X -Dgit='$git' release:prepare from the command line, to see if it works.
Does Jenkins store the projects' source code somewhere, such that I can go to that folder and call Maven?
If yes, then where?
Yes, It Stores the project files for the job by default at
/var/lib/jenkins/workspace/{your-job-name}
This is where jenkins suppose the project files to be present or it pulls it from a source before start working/building from it.
Quote from Andrew M.:
"Hudson/Jenkins doesn't quite work that way. It stores configurations and job information in /var/lib/jenkins by default (if you're using the .deb package). If you want to setup persistence for a specific application, that's something you'll want to handle yourself - Hudson is a continuous integration server, not a test framework.
Check out the Wiki article on Continuous Integration for an overview of what to expect."
From this Question on serverfault.
This worked for me:
/var/jenkins/workspace/JobNameExample
but, if your build machine (node) is a different than the one where Jenkins is running (manager), You need specify it:
/var/jenkins/workspace/JobNameExample/label/NodeName
Where you can define label too:
jenkins stores its workspace files currently in /var/jenkins_home/workspace/project_name
I am running from docker though!

How to get the sonar-report.json file created with sonarqube?

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

Unit test code analysis using "sonar.*" property and maven-sonar-plugin

I'm trying to do code analysis of Java unit test using maven sonar plugin. But the plugin doesn't seem to take into account my sonar properties "sonar.*". I've tried to modify simple examples and it did work either. According to MSONAR-70, the issue has been fixed and I'm using the version 2.4.
For the test, I've tried it on a simple case:
Clone sonar-examples.git
use the project sonar-examples/projects/languages/java/maven/java-maven-simple as example
Renamed src/main to src/test
In the pom.xml, add to the properties section :
<sonar.sources>src/test/java</sonar.sources>
<sonar.binaries>target/test-classes</sonar.binaries>
Run mvn sonar:sonar.
--> the code analysis didn't took into account my settings. The project is created on SonarQube but code as not been analyzed.
If I use the sonar-runner command line, it's analyzing the code:
sonar-runner [...] -Dsonar.sources=src/test/java
-Dsonar.binaries=target/test-classes
-Dsonar.language=java
-Dsonar.sourceEncoding=UTF-8
-Dsonar.projectKey=org.codehaus.sonar:example-java-maven
-Dsonar.projectName="Simple Java Maven Project"
-Dsonar.projectVersion=1.0-SNAPSHOT
According to a previous revision of the question, the OP solved their problem like this:
We were using SonarQube 4.0 version. Updating the version to 4.4, made the properties be taken into account.
That was in 2014; the current version now is 5.5.
The steps to upgrade can be found here:
Stop the old SonarQube server
Download and unzip the new SonarQube distribution in a fresh directory, let's say NEW_SONARQUBE_HOME.
Start it using the default H2 database and use the update center to install the plugins you need.
Manually install any custom plugins.
Stop the new server.
Update the content of the sonar.properties and wrapper.conf files located in the NEW_SONARQUBE_HOME/conf directory with the content of the related files in the OLD_SONARQUBE_HOME/conf directory (web server URL, database settings, etc.). Do not copy-paste the old files.
If a custom JDBC driver is used, copy it into NEW_SONARQUBE_HOME/extensions/jdbc-driver/.
Back up your database.
Remove the data/es directory.
Start the new web server
Browse to http://localhost:9000/setup (replace "localhost:9000" with your own URL) and follow the setup instructions.

Setting an Endpoint in Jenkins

I currently have a SoapUI project which I intend to have executed periodically (every 5 minutes) in Jenkins. I've completed the following thus far:
Created the relevant directory in the Workspace i.e workspace\SOA\SOAProject\src\test\soapui\SoapUIProject.xml
I've configured a pom.xml which sits in the SOAProject folder alongside the src folder
I've created a Jenkins job (I've chosen a Maven project, although it should not be an issue if I had chosen a freestyle job)
My question is, how do I set the endpoint?
I've done the following...
Build
**Root POM** pom.xml
Goals and options
testrunner.bat -e0.00.0.006:8040
Edit:
I've installed the EnvInject plugin. I'm not sure how to create the /properties file and what to put in their in order to set the execution environment?
I don't know the answer, but my suggestion is to get it running via command-line first. Once you figure out how to launch it without Jenkins, having Jenkins issue the same command because easy.
If you choose a Maven project, there is a useful plugin to set the endpoint and different propeties for the testSuites...
https://github.com/redfish4ktc/maven-soapui-extension-plugin

Resources