Utilisation d'une variable obtenue à l'aide d'une commande shell pré-build pour définir une option pour la génération Maven dans Hudson

Question

J'ai un travail Hudson qui exécute un objectif maven. Avant que cet objectif maven ne soit exécuté, j'ai ajouté une étape à exécuter avant le début de la construction, c'est un script shell qui obtient le numéro de version que je veux utiliser dans le champ 'Buts et options'.

Donc, dans ma configuration d'emploi, sous Build Environment J'ai vérifié le Configurer M2 supplémentaire Construire étapes boîte et a ajouté un script shell avant la construction. Le script ressemble à ceci:

export RELEASE={command to extract release version} 
echo $RELEASE 

Et puis sous la Construire section I point à mon 'pom racine'. Dans les objectifs et options Je veux donc être en mesure de faire quelque chose comme ceci:

-Dbuild.release.version=${RELEASE} deploy 

Où build.release.version est une propriété de maven référencé dans le POM. Cependant, puisque le shell ne semble pas rendre ses variables globales, cela ne fonctionne pas. Des idées? Le seul que j'ai est d'installer le plugin Envfile et obtenir le script shell pour écrire la propriété RELEASE dans un fichier, puis obtenir le plugin pour lire le fichier, mais l'ordre dans lequel tout est exécuté peut causer des problèmes et il semble qu'il doit y avoir une façon plus simple ... est là?

Merci d'avance.

Answer 1

Lorsque vous dites que cela ne fonctionne pas, voulez-vous dire que votre variable RELEASE n'est pas passée à la commande maven? Je crois que le problème est que, par défaut, chaque ligne du script shell est exécutée séparément, donc les variables d'environnement sont perdues.

Si vous voulez que le script entier shell à exécuter comme si elle était un fichier de script, faire la première ligne:

#!/bin/sh 

Je pense que cela est décrit dans les informations d'aide à côté de l'étape de génération de script shell (et si je me trompe, c'est un bon endroit pour chercher la bonne syntaxe).

Answer 2

Je voulais récemment faire la même chose, MAIS je ne sais pas s'il est possible d'exporter des valeurs d'un shell de préconfiguration vers l'environnement de travail. S'il y a un plugin Hudson pour cela, je l'ai manqué. Ce qui fonctionnait, cependant, était une configuration similaire à celle que vous proposiez: avoir le script shell de pré-construction écrire les valeurs souhaitées dans un fichier de propriétés dans l'espace de travail, puis utiliser le Parametrized Trigger Plugin pour déclencher un autre travail qui fait le travail (dans votre cas, invoquez le travail Maven). Le plugin peut être configuré pour lire les paramètres qu'il transmet depuis le fichier de propriétés. Ainsi, le premier travail a juste le script shell et les déclencheurs de post-construction, et le deuxième fait le travail actuel, ayant les paramètres corrects disponibles comme variables d'environnement.

idée générale du script shell:

echo "foo=bar 
baz=`somecmd`" > build.properties 

Et pour vos objectifs et options, quelque chose comme:

-Dbuild.release.version=${foo} deploy 

Certes, ce n'est pas aussi élégant que l'on pourrait désirer, mais a vraiment bien pour nous, puisque notre build a été cassé en plusieurs travaux pour commencer, et nous pouvons réellement réutiliser les autres travaux que le premier déclenche (c'est-à-dire, les invoquer avec des paramètres différents).