Plugin Jenkins Git: Comment créer une balise spécifique?


120

J'ai des problèmes pour que Jenkins crée une balise spécifiée. La balise fait partie d'une construction paramétrée, mais je ne sais pas comment la transmettre au plugin git pour simplement construire cette balise. Cela a pris 3 heures de ma journée et j'ai concédé la défaite aux maîtres au débordement de pile.


Vous voulez dire que c'est différent de stackoverflow.com/questions/7157170/... ? (troisième résultat de google.com/… )
VonC

1
"Cela a pris 3 heures de ma journée" - Je ne suis pas si paresseux que 3 heures de ma journée n'incluaient pas tous les liens que je pouvais trouver sur Google :)
sksamuel

1
Etes-vous sûr de vouloir procéder de cette façon? Vous rendez-vous compte que le balisage dans git ne s'adapte pas ? Peut-être pourriez-vous simplement utiliser une tâche "exécuter le shell" pour écrire un script afin de récupérer la balise / révision que vous voulez vraiment ?
mpontillo

Réponses:


222

J'ai pu le faire en utilisant le paramètre "branches à construire":

Branch Specifier (blank for default): tags/[tag-name]

Remplacez [tag-name] par le nom de votre tag.


5
Je ne sais pas pourquoi cela n'a pas plus de +1. Cette entrée de blog erics-notes est déroutante. Ceci est simple et fonctionne très bien. Merci!
Cody S

3
A très bien fonctionné pour moi. Merci. Mon paramètre s'appelait RELEASE_TAG, j'ai donc utilisé des balises / $ {RELEASE_TAG} comme valeur pour le spécificateur de branche.
Wesley Womack

3
Impossible de faire fonctionner cela. Pour une raison quelconque, vous ne pouvez pas vérifier la balise. J'obtiens: 'ERREUR: Impossible de trouver une révision à construire. Vérifiez le référentiel et la configuration de la branche pour ce travail. ' Je spécifie tags / 3.0.1, j'ai également essayé * / tags / 3.0.1 J'ai vérifié que la balise existe.
lostintranslation

1
Lorsque j'essaye de faire ce qui est suggéré dans cette réponse, chaque sondage du référentiel déclenche une compilation. Le journal d'interrogation git montrera en permanence que la "dernière révision construite" est la révision de la balise mais que la "dernière révision de la tête distante est" est la révision de la plus récente HEAD. La logique du plugin git semble comparer ces deux révisions, qui dans mon dépôt sont toujours inégales et donc une nouvelle construction est toujours déclenchée.
Louis

Cela doit sûrement être la bonne réponse, cela a fonctionné pour moi et c'est tellement simple. Je n'interroge pas le repo cependant, donc je suppose qu'il y a toujours ce problème.
Jeremy

76

Aucune de ces réponses ne me suffisait, en utilisant Jenkins CI v.1.555, le plugin Git Client v.1.6.4 et le plugin Git 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û concocter une solution à partir des différentes réponses ainsi que du billet de blog "build a Git tag" cité par Thilo .

  1. Assurez-vous de pousser votre balise vers le référentiel distant avec git push --tags
  2. Dans la section "Git Repository" de votre travail, sous la rubrique "Gestion du code source", 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 actuel).

L'ajout de Refspec pour moi s'est avéré essentiel. Bien qu'il semblait que les dépôts git récupéraient toutes les informations distantes par défaut lorsque je les laissais vides, le plugin Git échouerait néanmoins complètement à trouver ma balise. Ce n'est que lorsque j'ai explicitement spécifié "obtenir les balises distantes" dans le champ Refspec que le plugin Git a pu identifier et construire à partir de ma balise.

Mise à jour 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 référentiel Git à la Stash Webhook to Jenkins : à chaque fois qu'une branche du référentiel est mise à jour dans une poussée, les travaux de construction de balise se déclencheront également à nouveau. Cela conduit à de nombreuses reconstructions inutiles des mêmes tâches de balise, encore et encore. J'ai essayé de configurer les travaux avec et sans l'option «Forcer l'interrogation à l'aide de l'espace de travail», et cela semblait n'avoir aucun effet. La seule façon que je pourrais empêcher Jenkins de faire les builds inutiles pour les tâches de balise est de vider 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 cela ne se produirait peut-être 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 une fois le travail réussi.


4
Pour "ajouter le texte suivant" au refspec ... si votre refspec était auparavant, +refs/heads/*:refs/remotes/origin/*il le sera maintenant +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/remotes/origin/tags/*. (Je n'ai pas beaucoup travaillé avec les refspecs, il a donc fallu quelques expérimentations pour apprendre que ce champ est délimité par des espaces.)
driftcatcher

1
Un +1 supplémentaire pour cette solution. Les solutions antérieures ne fonctionnaient pas non plus pour moi.
whitespy9

16

Vous ne pouvez pas dire à Jenkins de construire à partir d'un nom de référence? Si c'est le cas, 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 eu à modifier aucun fichier de configuration pour que TeamCity fonctionne.


Vous n'êtes pas la première personne à suggérer une ville d'équipe. Est-ce vraiment beaucoup mieux? Je pourrais le vérifier.
sksamuel

1
@monkjack J'ai essayé la même syntaxe sur l'un de mes dépôts et cela a fonctionné. Pouvez-vous lister vos balises actuelles? Êtes-vous sûr d'avoir spécifiquement poussé cette balise vers le repo distant avecgit push --tags
Andrew T Finnell

4
Se rapprocher. Je ne poussais pas les balises à distance, mais maintenant je le suis. Je peux faire en sorte que jenkins construise maintenant en utilisant refs / tags / harpercollins-1.0.16, mais il insiste toujours sur la construction de la tête, peu importe ce que j'y ai mis. J'ai confirmé que la télécommande a la balise (peut le voir dans gitweb) et faire un instantané de cette balise confirme que tout y est correctement.
sksamuel

6
TeamCity est propriétaire, ce qui le rend pratiquement inutile.
argot

2
Oh oui, passer de l'outil gratuit au commercial est le bon choix! Lorsque jetbrains réinvente la roue et crée un nouveau bug tracker, proposerez-vous à d'autres de passer de bugzilla à ça?
m1ld

11

Si vous utilisez des pipelines Jenkins et que vous souhaitez extraire une balise spécifique (par exemple: un TAGparamètre 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
  }
}

9

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 le paramètre comme variable dans un même champ «Branches à construire», c'est-à-dire $ {Branch_to_build}.
  3. vous pouvez installer Git Parameter Plugin qui vous fournira des fonctionnalités en listant toutes les branches et balises disponibles.

1
En effet, le simple fait de saisir un nom de tag a fonctionné pour moi aussi. Bien que la documentation à ce sujet dans le plugin git dise encore que cela ne devrait pas fonctionner: "<tagName>: cela ne fonctionne pas car la balise ne sera pas reconnue comme une balise. Utilisez plutôt refs / tags / <tagName>."
Zitrax

Cela a fonctionné pour moi dans Jenkins 1.532.3, je viens de spécifier la version de la balise (par exemple 1.0.1) dans le champ branches à construire.
andre

9

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

entrez la description de l'image ici

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

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


C'est génial pour créer toutes les balises, merci! L'ajout de refspecétait l'astuce en cliquant sur le bouton Avancé.
styfle

9

J'ai défini le champ Advanced-> 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.

MISE À JOUR 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 d'extraction. Veuillez annuler ceci comme réponse acceptée. J'ai fini par obtenir une solution fonctionnelle en suivant le post de gotgenes dans ce fil (30 mars). Le problème mentionné dans cet article de déclenchement inutile de builds n'était pas un problème pour moi, car mon travail est déclenché à partir d'un travail en amont, et non de l'interrogation de SCM.

MISE À JOUR AVR-2018 - Notez dans les commentaires que cela fonctionne pour une personne et est d'accord avec la documentation Jenkins.


Je voulais juste noter que - quatre ans après la publication de cette réponse - utiliser refs/tags/<tagname>est ce que la documentation Jenkins dit qu'il faut utiliser, et cela fonctionne très bien pour moi. Peut-être que le plugin était bogué au moment de la publication originale, mais ... en avril 2018, c'est la bonne réponse.
evadeflow

Mise à jour de mon commentaire précédent: en fait, j'ai constaté que je pouvais omettre le refs/tagspréfixe et simplement l'utiliser <tagname>. YMMV, mais ... ça marche bien pour mes besoins.
evadeflow

3

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

J'ai également dû définir le nom du référentiel (sur "origin" dans mon cas) afin de pouvoir le référencer dans le Refspec (sinon, il utiliserait apparemment un nom généré aléatoirement).


2

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

  • a créé une nouvelle branche jenkins-targetet a demandé à Jenkins de suivre cela
  • fusionner à partir de la branche ou de la balise que je veux construire sur le jenkins-target
  • une fois que la construction fonctionnait, que les tests réussissaient, etc., créez simplement une balise à partir de la jenkins-targetbranche

Je ne sais pas si cela fonctionnera pour tout le monde, mon projet était assez petit, pas trop de balises et de trucs, mais c'est très facile à faire, ne pas avoir à jouer avec les refspecs et les paramètres et tout ça :-)


J'aime cette approche très simple.
zochhuana

2

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/*

Spécificateur de branche: origin/tags/1.2.3-alpha*

Vous pouvez également cocher " Construire lorsqu'une modification est envoyée sur GitHub " pour déclencher la transmission, mais vous devez ajouter une action "Créer" au webhook


1

Ajout de mes deux cents ici car je n'ai pas vu de réponse qui utilise l'option "Construire avec des paramètres" dans Jenkins.

Ici, j'utilise la console de navigateur Jenkins CI pour le projet starwars_api et j'ai pu construire directement avec "Build with parameters" avec la valeur refs / tags / tag-name

  1. choisissez l'option "construire avec des paramètres".
  2. ajouter de la valeur dans la zone comme "refs / tags / tag_142" (tag_name = tag_142 pour mon exemple)

construire avec le nom de la balise ref

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.