I try to run sonar tests with maven in my Jenkins pipeline project. The documentations says if the sonar is configured globally and you use the withSonarQube step the environment variables with the globally configured sonar properites are injected. So far so good.
http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins#AnalyzingwithSonarQubeScannerforJenkins-AnalyzingwithSonarQubeScannerforMaven
My pipeline config looks like:
def stash = '********'
def branch = 'dev'
stage('git') {
node {
git branch: branch, credentialsId: 'Buildserver-Private.key', url: stash
}
}
stage('build') {
node {
//....
}
}
stage('sonar') {
node {
withSonarQubeEnv('Sonar') {
sh 'mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar'
}
}
}
The build fails because the sonar plugin trys to connect to the default h2 database instead of the configured one. If i check the log, there are no sonar properties passed to maven.
Injecting SonarQube environment variables using the configuration: Sonar
[Pipeline] {
[Pipeline] tool
[Pipeline] sh
[***********] Running shell script
+ cd .
+ /var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3_3_9/bin/mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar
[INFO] Scanning for projects...
[...]
[INFO] --- sonar-maven-plugin:3.2:sonar (default-cli) # *******.project.build ---
[INFO] User cache: /var/lib/jenkins/.sonar/cache
[INFO] SonarQube version: 4.5.6
[INFO] Default locale: "en_US", source code encoding: "UTF-8" (analysis is platform dependent)
12:23:17.971 INFO - Load global referentials...
12:23:18.071 INFO - Load global referentials done: 102 ms
12:23:18.102 INFO - User cache: /var/lib/jenkins/.sonar/cache
12:23:18.109 INFO - Install plugins
12:23:18.176 INFO - Install JDBC driver
12:23:18.183 INFO - Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
Why is my config ignored? What does the documentation mean if it says?
Since version 2.5 of the SonarQube Scanner for Jenkins, there is an
official support of Jenkins pipeline. We provide a 'withSonarQubeEnv'
block that allow to select the SonarQube server you want to interact
with. Connection details you have configured in Jenkins global
configuration will be automatically passed to the scanner.
It seems they are not ...
Has anybody an idea what am I missing?
You are using an old version of SonarQube (4.5.6, the previous LTS) that requires to pass DB connection parameters (URL, login, password) to the scanners - which is a security issue. withSonarQubeEnv does not propagate those settings in order to fix this flaw.
Since SonarQube 5.2, these parameters are no longer required. So you have to use a version that is more recent. I suggest you to upgrade to the latest LTS version of SonarQube (5.6).
Related
i have an sbt project in jenkins, created the project as jenkins pipeline project, i have installed sbt in jenkins, i have checked the auto install checkbox and select the version number 1.2.8
here is my jenkins file
pipeline {
agent any
stages {
stage('Reload') {
steps {
echo "Reloading..."
//sh "sbt reload"
sh "${tool name: 'sbt1.2.8', type: 'org.jvnet.hudson.plugins.SbtPluginBuilder$SbtInstallation'}/bin/sbt compile"
}
}
}
}
and here is sbt settings in jenkins
here is jenkins console logs
+ /var/lib/jenkins/tools/org.jvnet.hudson.plugins.SbtPluginBuilder_SbtInstallation/sbt1.2.8/bin/sbt compile
[0m[[0m[0minfo[0m] [0m[0mLoading settings for project interpret-backend-project-jenkinsfile-build from plugins.sbt ...[0m
[0m[[0m[0minfo[0m] [0m[0mLoading project definition from /var/lib/jenkins/workspace/interpret-backend-project-jenkinsfile/project[0m
[0m[[0m[0minfo[0m] [0m[0mLoading settings for project interpret-backend-project-jenkinsfile from build.sbt ...[0m
[0m[[0m[0minfo[0m] [0m[0mSet current project to interpret (in build file:/var/lib/jenkins/workspace/interpret-backend-project-jenkinsfile/)[0m
[0m[[0m[0minfo[0m] [0m[0mExecuting in batch mode. For better performance use sbt's shell[0m
[0m[[0m[32msuccess[0m] [0m[0mTotal time: 4 s, completed Nov 25, 2020, 4:53:05 PM[0m
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
[Checks API] No suitable checks publisher found.
Finished: SUCCESS
[0m[[0m[0minfo[0m] [0m[0m why is this displaying how can i fix this ?
These are ANSI color codes. You can either embrace them to have colorful logs or disable them.
To enable colors in Jenkins you can modify your pipeline definition:
pipeline {
...
options {
ansiColor('xterm')
}
...
}
This is a reference to the AnsiColor plugin.
If you can't use this plugin and want to disable colors in sbt logs, you can do that by modifying sbt.color option. For example, by launching sbt with -Dsbt.color=false (I see that you can add this to in the UI) or by adding it to the SBT_OPTS environment variable:
pipeline{
...
environment {
SBT_OPTS = "${SBT_OPTS} -Dsbt.color=false"
}
...
}
Check out sbt docs and take a look at the sbt.ci option as well, it should be automatically set on Jenkins.
I'd like to run SonarQube Scanner from a Jenkins pipeline and I followed the documentation.
Regarding the error, it seems that the scanner is present but some commands are not found. My jenkins instance runs in a docker.
Jenkins version : 2.46.1
SonarQube Scanner : 2.6.1
+ /var/lib/jenkins/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner/bin/sonar-scanner
/var/lib/jenkins/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner/bin/sonar-scanner: line 56: which: command not found
/var/lib/jenkins/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQube_Scanner/bin/sonar-scanner: line 66: exec: : not found
In the sonar-scanner script, there is this block
if [ -n "$JAVA_HOME" ]
then
java_cmd="$JAVA_HOME/bin/java"
else
java_cmd="$(which java)"
fi
And given that my JAVA_HOME was unset, the script called which and the command is not installed inside my container.
As a workaround, I set the env variable JAVA_HOME.
Make sure the PATH is complete, or check if resetting it is enough
def sonarqubeScannerHome = tool name: 'SonarQubeScanner', type: 'hudson.plugins.sonar.SonarRunnerInstallation'
withEnv(["PATH=/usr/bin: ..."]) {
// Your call to Sonar
sh "${sonarqubeScannerHome}/bin/sonar-scanner -e -Dsonar.host.url=..."
}
I used the setup from "Execute SonarQube Scanner within Jenkins 2 Pipeline", but with Sonar 2.5, there is an official support of Jenkins pipeline:
def scannerHome = tool 'SonarQube Scanner 2.8';
withEnv(["PATH=/usr/bin: ..."]) {
withSonarQubeEnv('My SonarQube Server') {
sh "${scannerHome}/bin/sonar-scanner"
}
}
I'm trying to push my artifacts to Artifactory with Jenkins Pipeline, which call Gradle tool.
I am following the examples published on GitHub:
Example1
Example2
My Jenkins Pipeline script:
stage('Perform Gradle Release') {
//ssh-agent required to perform GIT push (when tagging the branch on release)
sshagent([git_credential]) {
sh "./gradlew clean release unSnapshotVersion -Prelease.useAutomaticVersion=true -Prelease.releaseVersion=${release_version} -Prelease.newVersion=${development_version}"
}
// Create an Artifactory server instance
def server = Artifactory.server('my-artifactory')
// Create and set an Artifactory Gradle Build instance:
def rtGradle = Artifactory.newGradleBuild()
rtGradle.resolver server: server, repo: 'libs-release'
rtGradle.deployer server: server, repo: 'libs-release-local'
//Use Gradle Wrapper
rtGradle.useWrapper = true
//Creates buildinfo
def buildInfo = Artifactory.newBuildInfo()
buildInfo.env.capture = true
buildInfo.env.filter.addInclude("*")
// Run Gradle:
rtGradle.run rootDir: "./", buildFile: 'build.gradle', tasks: 'clean artifactoryPublish', buildInfo: buildInfo
// Publish the build-info to Artifactory:
server.publishBuildInfo buildInfo
}
My Gradle file is very light, I'm just using the plugin Gradle Release Plugin to perform gradle release.
When executing the pipeline, it fails with this message:
:artifactoryPublish
BUILD SUCCESSFUL
Total time: 17.451 secs
ERROR: Couldn't read generated build info at : /tmp/generated.build.info4898776990575217114.json
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
hudson.model.Run$RunnerAbortedException
at org.jfrog.hudson.pipeline.Utils.getGeneratedBuildInfo(Utils.java:188)
at org.jfrog.hudson.pipeline.steps.ArtifactoryGradleBuild$Execution.run(ArtifactoryGradleBuild.java:127)
at org.jfrog.hudson.pipeline.steps.ArtifactoryGradleBuild$Execution.run(ArtifactoryGradleBuild.java:96)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousStepExecution.start(AbstractSynchronousStepExecution.java:40)
...
Finished: FAILURE
When I check on the server, there is no such file /tmp/generated.build.info4898776990575217114.json (the user has of course permission to write to /tmp).
Thanks for your help.
[EDIT] It is weird, but I found some files named "buildInfo2408849984051060030.properties", containing the informations. The name is not the same, neither the format, and these files are stores on my Jenkins machine, not my slave executing the pipeline.
Thanks #tamir-hadad, it has indeed been fixed on 2.8.2.
Does anyone knows for which reasons a SonarQube Scanner analysis could be skipped ?
$ sonar-scanner -X -Dsonar.host.url=https://sonarqube.com -Dsonar.login=$SONAR_TOKEN
08:59:10.162 INFO: Scanner configuration file: /home/travis/.sonarscanner/sonar-scanner-2.8/conf/sonar-scanner.properties
08:59:10.166 INFO: Project root configuration file: /home/travis/build/armadito/glpi/plugins/armadito/sonar-project.properties
08:59:10.182 INFO: SonarQube Scanner analysis skipped
The command "sonar-scanner -e -X -Dsonar.host.url=https://sonarqube.com -Dsonar.login=$SONAR_TOKEN" exited with 0.
Finally, I found out that travis-ci's sonarqube addon set by itself the following environnment variable :
export SONARQUBE_SKIPPED=true
With the following message :
Skipping SonarQube Scan because this branch is not master or it does not match declared branches
Indeed, I was working on a different branch: DEV.
Thus, the solution is the following, in .travis.yml :
sonarqube:
branches :
- DEV
And in sonar-project.properties :
sonar.branch=DEV
I have added branch under addons in travis.yml and also sonar branch in sonar properties file, but still SonarQube analysis gets skipped. how to fix this?
addons:
sonarqube:
token:
secure: "XXXXXXXXXXXXXXXXXXXXXXXXXX"
branches :
develop
added in travis.yml
and in sonar-project.properties, I have added this key as well
sonar.branch=develop
but travis has always this
$ export SONARQUBE_SKIPPED=true
0.41s$ sonar-scanner
INFO: Scanner configuration file: /home/travis/.sonarscanner/sonar-scanner-2.8/conf/sonar-scanner.properties
INFO: Project root configuration file: /home/........../sonar-project.properties
INFO: SonarQube Scanner analysis skipped
I'm puzzled why Gradle's uploadArchive is uploading artifacts from other configurations. My understanding is that when you declare a configuration it will get an upload task for you and when called it will upload the artifacts assigned to its configuration.
That's not the behavior I'm seeing:
apply plugin: 'base'
configurations {
foo
}
task fooIt(type: Zip) {
from 'blah.txt'
baseName 'foo'
}
task barIt(type: Zip) {
from 'blah.txt'
baseName 'bar'
}
artifacts {
foo fooIt
}
repositories {
flatDir {
name 'local'
dirs 'repo'
}
}
uploadArchives {
repositories {
add project.repositories.local
}
}
uploadFoo {
repositories {
add project.repositories.local
}
}
In this example there are no artifacts assigned to the archives configuration but when I call gradle uploadArchives it will upload foo's artifacts.
$ gradle -i uploadArchives
All projects evaluated.
Selected primary task 'uploadArchives' from project :
Tasks to be executed: [task ':fooIt', task ':uploadArchives']
:fooIt (Thread[Daemon Thread 17,5,main]) started.
:fooIt
Skipping task ':fooIt' as it is up-to-date (took 0.008 secs).
:fooIt UP-TO-DATE
:fooIt (Thread[Daemon Thread 17,5,main]) completed. Took 0.017 secs.
:uploadArchives (Thread[Daemon Thread 17,5,main]) started.
:uploadArchives
Executing task ':uploadArchives' (up-to-date check took 0.0 secs) due to:
Task has not declared any outputs.
Publishing configuration: configuration ':archives'
Publishing to Repository 'local'
Published :gradle:unspecified:foo.zip to file:/private/tmp/gradle/repo/foo-unspecified.zip
Published :gradle:unspecified:ivy.xml to file:/private/tmp/gradle/repo/ivy-unspecified.xml
:uploadArchives (Thread[Daemon Thread 17,5,main]) completed. Took 0.017 secs.
BUILD SUCCESSFUL
Two questions out of this:
Why is fooIt getting executed?
Why is uploadArchives uploading foo's artifacts?
Thanks
$ gradle --version
------------------------------------------------------------
Gradle 2.1
------------------------------------------------------------
Build time: 2014-09-08 10:40:39 UTC
Build number: none
Revision: e6cf70745ac11fa943e19294d19a2c527a669a53
Groovy: 2.3.6
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.7.0_45 (Oracle Corporation 24.45-b08)
OS: Mac OS X 10.10.2 x86_64
The archives configuration contains all artifacts from all configurations. I believe the confusion comes from the fact that you can also add artifacts directly to the archives configuration if you want. That being the case, the uploadArchives task will always upload all the declared artifacts. If you want to upload a subset of your artifacts then you should call the upload<<ConfigurationName>> task.