Project version from maven to sonar using hudson

Question

I use maven2, hudson and sonar when doing sonar analysis - I would like to somehow add Hudson build # to the maven project version

The project version changes every 2 weeks - this is an example in the first 2 weeks:

<version>abc-SNAPSHOT</version> 

in two weeks, the next version may look something like this:

 <version>xyz-SNAPSHOT</version> 

I want to add construct # to the version already present in pom, which is selected and passed to sonar

Note:

 -Dsonar.projectVersion=xyz-SNAPSHOT-${BUILD_NUMBER} 

Here - I hardcode the version and dynamically pass the assembly #

what I want is the ability to dynamically select a version from maven (without changing it) and simply add dynamically dynamically

any ideas on how this can be achieved? Thanks, Satish

Answer 1

You can use the Groovy script to read the version and set the environment variable: Getting the Maven version in Jenkins

I used this script to parse the version:

 def project = new XmlParser().parse("/pom.xml") def artifactId = project.artifactId.text().trim() def version = project.version.text().trim() println "ArtifactId: [" + artifactId + "]" println "Version: [" + version + "]" 

After setting the "Advanced Properties" field with: -Dsonar.projectVersion = $ {MAVEN_VERSION} - $ {BUILD_NUMBER}

If Jenkins does not receive the variable, try setting: https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin

Answer 2

This is not a sonar problem. This is Maven version control.

Pictures are intended for dynamic use. You will find under the hood that Maven saves time stamped versions in your Maven repository (I don't know how these timestamps could be passed to Sonar, which is probably what you would like). Snapshot assemblies are ideal for CI workstations. software that is never used by non-developers.

What I recommend is that you either stop using snapshots (create an “issue” each time), or simply accept the fact that there are two kinds of builds in Maven. My rule is that if the code is used by others, then it is no longer a snapshot and should be considered a release. This creates problems for emerging methodologies, such as continuous deployment ..... If every assembly goes into production (or production copy), then snapshots become inappropriate.

Creating a release every time is not so bad. First of all, a naming convention, I would recommend:

 <major>.<minor>.<patch>.<hudson build num> 

The Maven Release Plugin will automate most of the pain in managing release details (POM update, tagging your SCM system). Finally, there is also a useful M2_Release plugin that allows you to run a release from a Hudson GUID.

Answer 3

Thanks to Andre for pointing me to another link. I tried, but ran into some problems, as indicated in the comments Assuming I did this just a workaround, and is there a better solution? (I use Hudson) So I defined a new Job in Hudson (built the Maven 2/3 (Legacy) project) Here I defined "Groovy PostBuild" I copied the code into the link that Andrew pointed me to:

 import hudson.model.*; import hudson.util.*; def thr = Thread.currentThread(); def currentBuild = thr?.executable; def mavenVer = currentBuild.getParent().getModules().toArray()[0].getVersion(); def newParamAction = new hudson.model.ParametersAction(new hudson.model.StringParameterValue("MAVEN_VERSION", mavenVer)); currentBuild.addAction(newParamAction); 

Then I “Trigger parameterizes the assembly to other projects” and mentioned a job in which I wanted a version of maven as mentioend in pom

Parameter defined - $ {MAVEN_VERSION}

Then I was able to get the value of this parameter in a "different" task

So, thanks first to Andre - he gave me a solution. I am curious to find out if this is a good approach. The other question I have (maybe I will start a new thread) is how the Hudson’s “Free Style” assignment differs from the “project” Heritage Maven 2/3 "

The reason I ask is that the same Groovy script failed in the "free style" when it worked in the "Maven legacy"

Thanks Satish

Answer 4

The same need was resolved as suggested by Groovy pom parsing.

 import jenkins.util.*; import jenkins.model.*; def thr = Thread.currentThread(); def currentBuild = thr?.executable; def workspace = currentBuild.getModuleRoot().absolutize().toString(); def project = new XmlSlurper().parse(new File("$workspace/pom.xml")) def param = new hudson.model.StringParameterValue("project.version", project.version.toString()) currentBuild.addAction(new hudson.model.ParametersAction(param)); 

Add this script as a "Run Groovy script system" postulate (so you do not need to install Groovy) and paste the code into the "Groovy" command.

Answer 5

You can use this Jenkins feature: https://github.com/jenkinsci/jenkins/pull/933/files

Basically you can access env variables in the assembly displayed by Jenkins from Maven GAV info

• POM_DISPLAYNAME
• POM_DISPLAYNAME
• POM_VERSION
• POM_GROUPID
• POM_ARTIFACTID
• POM_PACKAGING
• POM_RELATIVEPATH