Est-il possible de Jenkins pour détecter automatiquement et de construire nouvellement créé des balises dans un repo git?

Il serait bien pour notre Jenkins serveur CI de détecter automatiquement, déployer et des balises de construction car ils sont créés dans notre dépôt Github.

Est-ce possible?

La pratique généralement suivie est de créer une balise après avoir réussi à construire et à déployer. Une raison pour laquelle vous voulez générer des balises plutôt que de maître?
Je suis l'aide de Tycho qui n'a pas de support pour mvn:date de sortie, mais le faire à votre façon fonctionne aussi bien.

InformationsquelleAutor Ricardo Gladwell | 2011-10-18

git jenkins

34

Avec la configuration suivante, vous pouvez faire un travail de construire tous les tags:
1. Faire le travail d'aller chercher des balises comme s'ils étaient des branches: Cliquez sur le bouton Avancé en dessous de l'adresse URL du référentiel et entrez le Refspec +refs/tags/*:refs/remotes/origin/tags/*
2. Ont construire tag "branches" avec la Direction générale Spécificateur de */tags/*
3. Permettre SCM de vote, de sorte que le travail détecte de nouvelles balises.
Cette approche a un inconvénient: La tâche sera de construire tous balises et pas seulement récemment ajouté des balises. Ainsi, après avoir créé le travail, il sera déclenchée une fois pour chaque balise existante. Donc, vous voulez probablement pour avoir le travail ne rien faire, d'abord, puis attendre jusqu'à ce que toutes les balises ont été traitées, et seulement ensuite configurer les étapes de génération que vous voulez faire pour chaque nouvelle balise.

Puisque les étiquettes ne changera pas dans git, le travail ne sera alors déclenché une seule fois pour chaque nouvelle balise.
- Avez-vous réellement obtenu ce travail? Je suis d'essayer d'activer, mais sans succès. La balise n'est pas sur la branche master. Dans Jenkins, Git plugin, définir un Nom d'origine et refspec comme " +refs/tags/*:refs/remotes/origin/tags/*'. Définir des branches pour construire que " /tags/', mais gardez se dit "Pas de candidat révisions d'ERREUR: impossible de trouver toute révision de construire. Vérifier le référentiel et de la direction générale de la configuration pour ce travail. Fini: l'ÉCHEC". Toutes les pensées? Ai-je besoin d'identifier les branches d'une certaine manière trop?
- Toutes mes excuses, j'ai commencé le dernier commentaire de mal. J'apprécie vraiment votre aide ici. Il apparaît soit je n'ai pas correctement, ou stackoverflow dépouillé de la '*', mais je vais re-vérifier et re-essayez. Merci encore pour cette façon de 'tromper' git dans le traitement des balises comme une branche.
- Malheureusement, comme indiqué ici, cette façon de déclenchement s'appuie sur de nouvelles balises semble être actuellement cassé.
- Mon problème est que la construction est déclenché au hasard chaque tellement souvent sans aucun changement dans le dépôt. Quelque chose est éteint :/
- Semble que cela ne fonctionne toujours pas. Construire pour moi, sur tous les sondages.
- Je viens de revérifier, et la solution fonctionne parfaitement pour nous. Nous sommes à l'aide de Jenkins 1.565.1, Git Plugin 2.2.4, et Git Client Plugin 1.15.0. Et nous sommes à l'aide de balises uniquement pour les sorties, c'est à dire il y a au plus une seule étiquette par commettre et on ne bouge pas les balises.
- This approach has one drawback un - autre- vous ne pouvez pas construire balise qui pointe à une précédente hachage de la tête. Pour par exemple, vous avez la suite de l'histoire: 550313e(commit1) -> 22ce31f(commit2) -> e31e663(commit3, head) Puis vous ajouter un nouveau tag: tag1 -> e31e663. Le travail sera déclenchée, MAIS après ce travail, vous ne serez pas en mesure de déclencher des emplois pour les livraisons 550313e/22ce31f
InformationsquelleAutor oberlies
17

De surmonter l'inconvénient de @oberlies réponse que toutes les balises sera construit, je suis à l'aide d'un déclencheur de construire à la place. Le déclenchement de construire utilise le même dépôt git et de la direction générale en tant que principal de génération et la suivante (post) etapes de construction.

Build -> Execute shell:
```
# Get the most recent release tag.
PATTERN="release-tag-[0-9][0-9]-[0-9][0-9][0-9][0-9]"
TAG=$(git log --tags=$PATTERN --no-walk --pretty="format:%d" | grep -m 1 -o $PATTERN)

# Due to a Jenkins limitation (https://issues.jenkins-ci.org/browse/JENKINS-8952)
# when passing environment variables we have to write the tag to a file and
# inject it later again.
mv release.properties release-old.properties || true
echo "TAG = $TAG" > release.properties

# Fail the build if the most recent release tag did not change.
! diff release.properties release-old.properties
```
Build -> Injecter des variables d'environnement:
```
Properties File Path: release.properties
```
Post-construire des Actions -> : Déclenchement paramétrable construire sur d'autres projets
```
Projects to build: <your main project>
Trigger when build is: Stable
Parameters: TAG=$TAG
```
Enfin, dans votre génération principal, cochez la case "Ce build est paramétrée" avec la chaîne de caractères du paramètre
```
Name: TAG
Default Value: <your release branch>
```
Et dans le "Code Source de gestion de la section" utiliser "$TAG" dans les "Branches pour construire" sur le terrain.

InformationsquelleAutor sschuberth
3

Vous pouvez installer un post-recevoir crochet, qui vérifie si une étiquette a été commis, et crée une accumulation dans jenkins.

Le crochet peut ressembler à quelque chose comme ceci [*]:
```
#!/usr/bin/env python

import sys
from subprocess import Popen, PIPE, check_call

def call_git(command, args):
    return Popen(['git', command] + args, stdout=PIPE).communicate()[0]
JENKINS = 'http://localhost:8002/jenkins'
TOKEN = 'asdf8saffwedssdf'
jobname = 'project-tag'

def handle_ref(old, new, ref):
     print 'handle_ref(%s, %s, %s)' % (old, new, ref)
     if not ref.startswith('refs/tags/'):
          return
     url = '%s/job/%s/buildWithParameters?token=%s&branch=%s' % (
        JENKINS, jobname, TOKEN, new)
     print "queueing jenkins job " + jobname + " for " + new
     check_call(["wget", "-O/dev/null", "--quiet", url])
if __name__ == '__main__':
    for line in sys.stdin:
        handle_ref(*line.split())
```
[*] note: ceci est juste une conversion rapide de légèrement différente de script, il est donc tout à fait probable qu'il y a quelques petits bugs ici. C'est surtout pour montrer l'idée.

Sur le jenkins côté, vous devez configurer un paramétrés au travail. Le seul paramètre est la "branche".
1. Cochez la case 'ce build est paramétrisée" et ajouter le paramètre
2. Dans le code source de gestion -> branches pour construire' mettre '$succursale"
Cela donne une assez sûre et solide, de façon à construire. Pour les tests, l'exécution d'une construction à travers l'interface web, il va demander la valeur du paramètre.

InformationsquelleAutor zbyszek
0

Dans le monde moderne (?) multi-direction des pipelines, de la construction des balises fonctionne comme suit.
1. Ajouter le "comportement" à la découverte de tags:
2. Utiliser le plugin De Base De La Branche D'Élaborer Des Stratégies pour ajouter une "stratégie de construction" pour les balises:
  
  N'oubliez pas d'ajouter une stratégie de construction pour les branches; le plugin désactive les paramètres par défaut complètement!
InformationsquelleAutor Raphael
-3

Vous pouvez utiliser l'option "Git de l'Éditeur" qui vient en partie de la Plugin Git pour créer une étiquette après avoir réussi à construire/deploy.
- Je pense que la question a été de construire des versions marqués par la version plugin maven.
InformationsquelleAutor leenasn

Vous devez vous connecter pour publier un commentaire.