version de projet de maven au sonar à l'aide hudson

Question

j'utilise maven2, hudson et sonar tout en faisant une analyse sonar - je voudrais une certaine façon d'ajouter l'Hudson construire # à la version maven du projet

La version du projet change toutes les 2 semaines - donc prendre un exemple dans les 2 premières semaines:

<version>abc-SNAPSHOT</version> 

au bout de deux semaines, la prochaine version pourrait être quelque chose comme:

<version>xyz-SNAPSHOT</version> 

ce que je veux est d'ajouter la construction # à la version déjà présente dans pom - qui est repris et transmis au sonar

REMARQUE:

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

Ici - je hardcoding la version et le passage dynamique la construction #

ce que je veux est d'être en mesure de choisir dynamiquement la version de Maven (sans le modifier) ​​et le # annexant simplement de construire dynamiquement

toute idée de la façon dont cela peut être réalisé? Merci, Satish

Answer 1

Vous pouvez utiliser le script Groovy pour lire la version et de mettre sur la variable d'environnement: Getting Maven Version in Jenkins

J'ai utilisé ce script sur le temps pour analyser la 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 + "]" 

Après set Champ "Propriétés supplémentaires" avec: -Dsonar.projectVersion = $ {MAVEN_VERSION} - $ {BUILD_NUMBER}

Si Jenkins ne reçoit pas la variable, essayez d'installer: https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin

Answer 2

Ce n'est pas vraiment un problème Sonar. C'est le versionnement du projet Maven.

Les instantanés sont conçus pour être dynamiques. Vous découvrirez sous le capot que Maven enregistre des versions horodatées dans votre dépôt Maven (je ne sais pas comment ces horodatages pourraient être transmis à Sonar, ce qui est peut-être ce que vous voulez). Les générations de clichés sont idéales pour les travaux de CI. logiciel qui n'est jamais utilisé par des non-développeurs. Ce que je recommanderais est d'arrêter d'utiliser des snapshots (construire une "release" à chaque fois), ou simplement accepter le fait qu'il existe deux types de build dans Maven. Ma règle est que si le code est utilisé par d'autres, ce n'est plus un instantané et devrait être traité comme une version. Cela crée des défis pour les méthodologies émergentes telles que le déploiement continu ... Si chaque génération passe en production (ou copie de production), les instantanés deviennent inutiles.

Construire une version à chaque fois n'est pas si grave. Tout d'abord, convention de nommage, je vous recommande:

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

Le Maven's release plugin permettra d'automatiser la plupart de la douleur dans la gestion des détails de la libération (mise à jour du POM, marquage de votre système SCM). Enfin, il y a aussi un M2_Release plugin utile qui vous permet de déclencher une version de Hudson GUI.

Answer 3

Merci André pour me montrant l'autre lien Je l'ai fait essayer, mais a été en cours d'exécution dans certaines questions comme indiqué dans les commentaires En supposant que je l'ai fait est juste une solution de contournement et il y a une meilleure solution? (J'utilise Hudson) J'ai donc défini un nouveau Job dans Hudson (Construire un projet Maven 2/3 (Legacy)) Ici, j'ai défini un "Groovy PostBuild" Copié le code dans le lien qu'André m'a indiqué:

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); 

je puis "Trigger build paramétrés sur d'autres projets" et mentionné le travail dans lequel je voulais la version Maven mentioend dans la pom

Définition d'un paramètre - $ {MAVEN_VERSION}

I était alors en mesure d'obtenir la valeur de ce paramètre i n ' « autre » emploi

Alors d'abord grâce à André - il m'a fourni une solution Je suis curieux de savoir si cela est une bonne approche une autre question que j'ai est (que je vais peut-être commencer un nouveau thread) est - comment un travail Hudson "style libre" diffère d'un "projet Maven 2/3"

La raison pour laquelle je demande est le même script Groovy échoué dans un "style libre" alors qu'il travaillait dans un "héritage Maven"

Merci, Satish

Answer 4

avait le même besoin et résolu que suggéré avec Groovy l'analyse du pom.

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)); 

Ajouter ce script comme une étape post de type « Exécuter système de script Groovy » (il est donc pas nécessaire d'installer Groovy) et collez le code dans la commande « Groovy ».

Answer 5

Vous pouvez utiliser cette fonction Jenkins: https://github.com/jenkinsci/jenkins/pull/933/files

Fondamentalement, vous pouvez accéder à des variables d'env à construire, cartographiée par Jenkins de Maven GAV information

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