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

Question

Ce serait bien pour notre serveur Jenkins CI pour détecter automatiquement, déployer et construire tags tels qu'ils sont créés dans notre dépôt Github.

Est-ce possible?

Answer 1

Avec la configuration suivante, vous pouvez faire un travail construit tous les tags:

1. Faites le travail comme si les balises chercher ils étaient branches: Cliquez sur le bouton Avancé ci-dessous l'URL du référentiel et entrez le Refspec +refs/tags/*:refs/remotes/origin/tags/*
2. Avez-il construire toutes les étiquettes "branches" avec la Direction Specifier */tags/*
3. Activer l'interrogation SCM, de sorte que le travail détecte de nouvelles balises.

Cette approche a un inconvénient: Le travail va construire tous et pas seulement les balises nouvellement ajoutés. Donc, après avoir créé le travail, il sera déclenchée une fois pour chaque balise existante. Donc, vous voulez probablement avoir le travail ne rien faire d'abord, puis attendre que toutes les étiquettes existantes ont été traitées, et seulement configurer ensuite les étapes de construction que vous voulez faire pour chaque nouvelle balise.

Étant donné que les balises ne changent pas git, le travail sera alors déclenché une seule fois pour chaque nouvelle balise.

Answer 2

Pour surmonter l'inconvénient de la réponse de @oberlies que tous les tags seront construits J'utilise une version spéciale déclencheur à la place. La construction de déclenchement utilise le même dépôt git et la branche comme la principale construction et les étapes de génération de suivants (POST).

Construire -> Exécuter 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

Construire -> Injecter variables d'environnement :

Properties File Path: release.properties

Actions post-construction ->: Trigger paramétrés construire sur d'autres projets

Projects to build: <your main project>
Trigger when build is: Stable
Parameters: TAG=$TAG

Enfin, lors de la construction principale, cochez « Cette construction est paramétré » avec le paramètre de chaîne suivante

Name: TAG
Default Value: <your release branch>

Et dans l'utilisation de la section "gestion du code source" "$ TAG" dans les "branches pour construire" champ.

Answer 3

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

Le crochet peut ressembler à 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 à partir d'un script un peu différent, il est donc tout à fait probable qu'il y ait quelques petits bugs ici. Ceci est la plupart du temps pour montrer l'idée.

Du côté de jenkins, vous devez configurer un emploi paramétrisé. Le seul paramètre est « branche ».

1. Vérifiez « cette version est paramétrées » et ajouter le paramètre
2. 'la gestion du code source -> branches à construire' Put '$ branche'

Cela donne une manière assez sûre et robuste à construire. Pour tester, exécuter une construction à travers l'interface web, il va demander la valeur du paramètre.

Answer 4

Dans le monde des pipelines multi-branche modernes (?), Les balises des travaux de construction comme suit.

1. Ajoutez le "comportement" à découvrir tags:
   
2. Utiliser le plugin Direction générale de base des stratégies de build pour ajouter une "stratégie de construction" pour les tags: Ne pas oublier d'ajouter une stratégie de construction pour les branches aussi bien; le plug-in désactive les paramètres par défaut complètement!

Answer 5

You can use the option "Git Publisher" which comes as part of the Git Plugin to create a tag after a successful build/deploy.