Hudson/Jenkins version plugin: version de sortie questions

Question

Je suis en train de mettre en place un nouveau projet hudson et trébuché sur le release plugin. Vous avez deux possibilités:

1. Ne pas définir les paramètres de chaîne releaseVersion et developmentVersion - puis le plugin version Maven utilise des valeurs par défaut. (La version 1.0.0-SNAPSHOT (svn) -> 1.0.0 sera publiée (tag dans svn) et 1.0.1-SNAPSHOT sera la prochaine version de développement.) Dans la plupart des cas cela nous suffit. Cependant, dans certains cas (par exemple, une version majeure devrait être construite), cela ne suffit pas.
2. Définissez ces deux valeurs (image de cp, marqueurs rouges) mais vous devez toujours les remplir et elles sont vides! Il est évidemment impossible d'utiliser les valeurs par défaut ou de les laisser vides. C'est pourquoi on a la possibilité d'ajouter preRelease et postRelease des actions comme des scripts etc. Cependant si le plugin serait un peu plus intelligent ce ne serait pas nécessaire imho.

Ma question est: Est-il possible sans utiliser avant/après scripts de compilation de libération pour obtenir le comportement voulu?

Le comportement souhaité est: Les champs releaseVersion et developmentVersion doivent être remplis avec la version/version actuelle + 1. Si cela n'est pas possible, laisser ces champs vides est également suffisant (si cela déclenche le comportement par défaut du plugin maven build). Si ces champs sont vides maintenant, maven sera appelé avec un paramètre vide et donc échouera.

(Dans différents projets, j'ai utilisé jenkins en combinaison avec le plugin de version artificielle qui est vraiment facile - Si une version devrait être publiée, une page est montrée où toutes les versions sont listées. l'utilisateur peut facilement changer les numéros.)

Answer 1

J'ai eu un problème similaire, mais la solution pour moi pourrait avoir des frais généraux importants dans votre situation.

Les tâches de ma configuration ne sont pas créées manuellement mais générées à l'aide de Job DSL Plugin. C'est le cas car de nombreux travaux similaires existent pour différents artefacts et la génération a tendance à arrêter les travaux de flocon de neige de différents utilisateurs.

Ma solution ressemble à ceci:

1. Pour chaque emploi dans la production: Interroger votre référentiel d'artefact pour la dernière version de l'artefact créé par le travail (Sonatype Nexus pour moi)
2. Generate les versions vous souhaitez afficher à un utilisateur (il suffit d'ajouter le fichier etc mineur)
3. Appliquer la version que le texte par défaut à votre paramètre de chaîne dans DSL Job (comme le montre here)
4. Relancez la génération dans un intervalle de jeu, de sorte que le emplois les plus susceptibles sho w les bonnes versions

Cela a été facilement possible pour moi, car Job DSL était déjà en place et le nom de chaque artefact fait partie du nom de travail. C'est loin d'être parfait, car il peut y avoir des moments dans le temps qui ne montrent pas la bonne version (juste après une nouvelle version quand la création du travail n'a pas été relancée).

Une autre option serait de créer un plugin Jenkins personnalisé pour cette tâche, mais cela entraînerait probablement encore plus de temps système. PS: Je peux essayer d'inclure d'autres exemples de code si cette solution est une route que vous voulez essayer.