Situation:
I want to analyze my project with SonarQube (5.4) triggered by Jenkins (1.642.4). It is a java project build with maven.
I see two ways to trigger the analysis:
Post Build Action "SonarQube analysis with maven" but it's deprecated, so I don't want to use it
Post Build Step "Execute SonarQube Scanner", is the recommended way.
Problem:
If I use the deprecated Post Build Action, the properties for sonar project configuration are derived automatically from the project pom.
It I use the recommended Post Build Step, I receive the Exception
You must define the following mandatory properties for 'Unknown': sonar.projectKey, sonar.projectName, sonar.projectVersion, sonar.sources
Undesired Solution:
The solution is to provide the required properties, via sonar-project.properties file in the java project or via parameters in Jenkins step.
IMHO: this is duplication. All relevant information is defined in the Maven pom: projectKey can be derived from artifactId, projectName and projectVerstion are same properties in maven. Especially the projectVersion is critical. I don't want to update the project version after each release (or write some code in release plugin to update it automatically).
What I want
I want to use the recommended Post Build Step in Jenkins, without redefine all project properties for all my project to make sonar happy. Instead sonar/jenkins/plugin/whatever should derive the properties from my maven pom file. Is there an additional plugin I can use? Can I reconfigure my Jenkins-Sonar-Plugin?
I don't want to provide any sonar specific information in my pom/project, because the project shouldn't care about sonar. It should contain only information required to build the project.
The documentation (although slightly confusing, see edit below) explains how to use a generic post-build step (leveraging environment variables), instead of the deprecated post-build action. in short:
install latest SonarQube Plugin (v2.4 as of now) in Jenkins
in System Config under SonarQube servers: check Enable injection of SonarQube server configuration as build environment variables
in the configuration of your Maven project:
check Prepare SonarQube Scanner environment
add a post-build step Invoke top-level Maven targets and leverage the injected environment variables in the Goals field e.g.:
$SONAR_MAVEN_GOAL -Dsonar.host.url=$SONAR_HOST_URL -Dsonar.login=$SONAR_AUTH_TOKEN
Edit: when the documentation says The Post-build Action for Maven analysis is deprecated. , it refers to the old post-build action which is not documented anymore. The paragraph after that warning (summarized in this answer) really is the recommended procedure. Illustration here if it's still not clear.
Using SonarQube Scanner as a post build step you can configure it with at least this properties in Analysis properties:
sonar.projectKey=${POM_ARTIFACTID}
sonar.projectName=${POM_DISPLAYNAME}
sonar.projectVersion=${POM_VERSION}
sonar.sources=src
sonar.java.binaries=target
sonar.language=java
sonar.sourceEncoding=UTF-8
POM_* variables are mapped by Jenkins from Maven GAV info, look here: https://github.com/jenkinsci/jenkins/pull/933/files
Related
We have an in-house developed MOJO that generates content and doesn't require you to have an existing project or POM. Think of the maven archetype plugin, where you can just run mvn [mojo]:[goal] and have maven just execute that goal without a POM.
This MOJO connects to a specific database instance in a specific environment, and generates some metadata for the contents of the database, so our testers can inspect the metadata and locate production-like data that has certain attributes they need for a given test.
When you execute the metadata mojo, maven resolves the MOJO from the available repo's (in our case an Artifactory repo), and it then does its work and returns. It does not create any artifacts or other outputs.
We use TeamCity as our CI server, but it also has metadata generation jobs so with one click a dev can kick of a metadata generation job against a specific database.
The problem with this is the Maven runner in TeamCity requires a POM. If TC hasn't already checked out a project from a VCS, or the project it's checked out doesn't have a POM, the maven runner won't do anything. In this case, there is nothing to check out (the MOJO is resolved from Artifactory) so there is no POM.
I can set up the TC job to use the Command Line runner and have it execute, say, mvn com.example:metadata-generate -DenvironmentName=UAT1, but then it's impossible to specify the maven settings file that maven should use.
So my question is, how do I do this? Is it possible to have the maven runner execute an arbitrary maven command without needing a POM? Alternatively, using the Command line runner, is it possible to have a TC job copy a specific maven settings file to the build agent so it can be referenced in the maven command as mvn com.example:metadata-generate -DenvironmentName=UAT1 -s {path-to-settings-file}?
So its turns out that TC handles pom-less maven builds just fine. My problem was that the MOJO was not declared to not require a project.
Comparing my MOJO with the MavenArchetypePlugin source, I needed to declare my MOJO with the class level javadoc tag #requiresProject false.
Once I had that in place, TC ran my pom-less job perfectly well. All I had to do was clear the Path to POM file: field in the TC build configuration and leave it blank.
You can customize the name of the pom file that you use as an argument into the maven build-step in the teamcity and use this as the second "build step".Lets call the parameter as pom.file.name
In the first step , resolve all the in-house dependencies that you have and set the name of the pom file you want to execute into the variable pom.file.name
If you want to know more about how to change tha value of a variable in teamcity, you can read about it here
I've been asked to get SonarQube up and running, but we'll be using maven instead of SonarQube Runner.
Is the sonar-project.properties configuration file only used for analysis with SonarQube Runner, or is it necessary for other analyzers, such as maven?
It is only for SonarQube Runner. If you want to pass extra properties to maven you have to pass it on command line with -D prefix. Example: mvn sonar:sonar -Dsonar.language=java.
Yes, as has been said, it is only for Sonar Runner because in this file you define your Project Name, Project Version, default locale from the source code of your Project and so on...
And in your case, using maven, the information like Project Name, Project Version and all about Project is defined in the pom.xml from your Project, and in the Maven you followed a folder structure and so you don't need to tell the source code locale.
In case of C# analysis also you need to add '-D' prefix. --
Something like this.
-Dsonar.language=cs
-Dsonar.dotnet.visualstudio.solution.file="EventProcessing.sln"
-Dsonar.gendarme.mode=
-Dsonar.gallio.coverage.tool=OpenCover
-Dsonar.dotnet.visualstudio.testProjectPattern=*.Tests*
My projects are built with Maven 3.0 and use the plugin build-helper to set the following properties at the initialization phase :
parsedVersion.majorVersion, parsedVersion.minorVersion
It works well for the build, where I also set sonar.branch=parsedVersion.majorVersion.parsedVersion.minorVersion
In Jenkins, I add the Post Build Step "Sonar analysis" (from Sonar plugin for Jenkins), it ends up with the following error:
Can not execute SonarQube analysis: Illegal character in query at index 108:
http://<sonar url>/sonar/batch_bootstrap/properties?project=com.x.y.<ArtifactId>:${parsedVersion.majorVersion}.${parsedVersion.minorVersion}
So the properties values were not instanciated correctly.
Did anyone encounter the issue ? is there a solution or is it a bug in Jenkins or Jenkins sonar plugin ?
You need to explicitly run the initialization phase.
Include -Dsonar.phase=initialize in your additional properties.
I use the git-describe maven plugin to replace the POMs <version>${describe}</version> placeholder. mvn deploy needs a custom parameter passed in order for it to properly use the actual git describe value.
I'm now using Jenkins to build the project every time we push to the repo however it too doesn't properly use the actual git-describe value.
The jenkins build artifacts always end named project-${describe}
Are there any suggestions on ways I can customize the file names or force it to use the git-describe result? Otherwise I may be back to manual versioning...
The version property does not allow variable substitution. The first link I found googling this was this SO question.
You'll have to use one of the versioning maven plugins. The maven release plugin is the most popular, but you might find that the versions maven plugin better meets your requirements.
Is it possible to do a Maven build using Build Forge? Currently we use Build Forge, ClearCase and ClearQuest with Ant scripts; would like to try a Maven build. Not sure if I can I have no test environment so don't want to mess up any thing and still learning all this stuff too
Maven can be invoked from any build automation framework.
Create a buildforge step that invokes your Maven build as follows:
mvn -s /path/to/maven/settings/files/mysettings.xml clean package
Explicitly selecting the settings file is recommended as this enables you customise the Maven configuration for each project.
Project isolation can be further enhanced by ensuring that each project has it's own local repository location (See the "localRepository" parameter in the settings file documentation)