Jenkins Git Plugin: comment construire une balise spécifique?

Aucune de ces réponses n'était suffisante pour moi, en utilisant Jenkins CI v. 1. 555, git Client plugin v. 1. 6.4, et git plugin 2.0.4.

Je voulais un travail à construire pour un référentiel Git pour une balise spécifique, fixe (c'est-à-dire non paramétrée). J'ai dû bricoler une solution à partir des différentes réponses plus le blog "construire un tag Git" cité par Thilo .

1. assurez-vous de pousser votre balise vers le référentiel distant avec git push --tags
2. dans le " dépôt Git" dans la section "Gestion du Code Source" de votre travail, cliquez sur "Avancé".
3. dans le champ Refspec, ajoutez le texte suivant: +refs/tags/*:refs/remotes/origin/tags/*
4. sous "Branches à construire"," spécificateur de branche", mettez */tags/<TAG_TO_BUILD> (en remplaçant <TAG_TO_BUILD> par votre nom de balise réel).

L'ajout du Refspec pour moi s'est avéré critique. Bien qu'il semble que les dépôts git récupéraient toutes les informations distantes par défaut quand je l'ai laissé vide, le plugin Git serait néanmoins complètement ne parviennent pas à trouver mon tag. Ce n'est que lorsque j'ai explicitement spécifié "get the remote tags" dans le champ Refspec que le plugin Git était capable d'identifier et de construire à partir de ma balise.

Update 2014-5-7: malheureusement, cette solution a un effet secondaire indésirable pour Jenkins CI (v. 1.555) et le mécanisme de notification push du dépôt Git à la Stash Webhook to Jenkins : chaque fois que une branche du dépôt est mise à jour dans un push, les travaux de construction de balises se déclencheront à nouveau. Cela conduit à beaucoup de reconstitutions inutiles des mêmes tâches de balise encore et encore. J'ai essayé de configurer les travaux à la fois avec et sans l'option "Forcer l'interrogation en utilisant l'espace de travail", et cela semblait n'avoir aucun effet. La seule façon d'empêcher Jenkins de faire les builds inutiles pour les travaux de balise est d'effacer le champ Refspec (c'est-à-dire, supprimer le +refs/tags/*:refs/remotes/origin/tags/*).

Si quelqu'un trouve une solution plus élégante, veuillez modifier cette réponse avec une mise à jour. Je soupçonne, par exemple, que peut-être cela cela n'arriverait pas si le refspec était spécifiquement +refs/tags/<TAG TO BUILD>:refs/remotes/origin/tags/<TAG TO BUILD> plutôt que l'astérisque fourre-tout. Pour l'instant, cependant, cette solution fonctionne pour nous, nous supprimons simplement le Refspec supplémentaire après le succès du travail.

Ne pouvez-vous pas dire à Jenkins de construire à partir d'un nom Ref? Si oui, alors c'est

refs/tags/tag-name

De toutes les questions que je vois sur Jenkins et Hudson, je suggère de passer à TeamCity. Je n'ai pas eu à éditer de fichiers de configuration pour que TeamCity fonctionne.

J'ai fait quelque chose comme ça et ça a marché:

Source Code Management

 Git    
    Repositories    


 Advance

Name: ref
Refspec : +refs/tags/*:refs/remotes/origin/tags/* 

 Branches to build  
 Branch Specifier (blank for 'any') : v0.9.5.2

Jenkins log a confirmé qu'il obtenait la source de la balise

Vérification de la révision 0b4d6e810546663e931cccb45640583b596c24b9 (v0.9.5.2)

Dans un dernier Jenkins (1.639 et supérieur), vous pouvez:

1. spécifiez simplement le nom de la balise dans un champ 'Branches à construire'.
2. dans une construction paramétrée, vous pouvez utiliser parameter comme variable dans un même champ 'Branches to build', c'est-à-dire ${Branch_to_build}.
3. vous pouvez installer Git Parameter Plugin qui vous fournira des fonctionnalités en répertoriant toutes les branches et balises disponibles.

J'ai défini le champ avancé - > Refspec sur refs/tags/[your tag name]. Cela semble plus simple que les diverses autres suggestions pour Refspec, mais cela a très bien fonctionné pour moi.

UPDATE 23/7/2014 - en fait, après d'autres tests, il s'avère que cela n'a pas fonctionné comme prévu. Il semble que la version HEAD était toujours en cours de vérification. Veuillez annuler ceci comme réponse acceptée. J'ai fini par obtenir une solution de travail en suivant le post de gotgenes dans ce fil (30 Mars). Le problème mentionné dans ce post de déclenchement inutile des builds n'était pas un problème pour moi, car mon travail est déclenché à partir d'un travail en amont, pas à partir de l'interrogation SCM.

UPDATE APR-2018 - Notez dans les commentaires que cela fonctionne pour une personne, et est d'accord avec la documentation de Jenkins.

Si vous utilisez des pipelines Jenkins et que vous voulez extraire une balise spécifique (par exemple: un paramètre TAG de votre build), voici ce que vous pouvez faire:

stage('Checkout') {
  steps {
    checkout scm: [$class: 'GitSCM', userRemoteConfigs: [[url: 'YOUR_GIT_REPO_URL.git', credentialsId: 'YOUR_GIT_CREDENTIALS_ID' ]], branches: [[name: 'refs/tags/${TAG}']]], poll: false
  }
}

J'ai pu amener Jenkins à construire une balise en définissant le spécificateur Refspec et branche comme détaillé dans cet article de blog .

J'ai également dû définir le nom du référentiel (à "ORIGINE" dans mon cas) afin que je puisse le référencer dans le Refspec (sinon il utiliserait apparemment un nom généré aléatoirement).

Ce que j'ai fait à la fin était:

• a créé une nouvelle branche jenkins-target, et a demandé à jenkins de suivre cela
• fusionnez à partir de la branche ou de la balise que je veux construire sur jenkins-target
• Une fois que la construction fonctionnait, teste etc, créez simplement une balise à partir de la branche jenkins-target

Je ne suis pas sûr que cela fonctionnera pour tout le monde, mon projet était assez petit, pas trop de tags et d'autres choses, mais c'est facile à faire, ne pas avoir à jouer avec refspecs et paramètres et autres :-)

Vous pouvez même créer un type de balise, par exemple 1.2.3-alpha43, en utilisant des caractères génériques:

Refspec: +refs/tags/*:refs/remotes/origin/tags/*

Direction de la spécificateur: origin/tags/1.2.3-alpha*

Vous pouvez également cocher "Build quand une modification est poussée vers GitHub " pour déclencher la poussée, mais vous devez ajouter "create" action au webhook