Ist es möglich, für die Jenkins automatisch erkannt und bauen neu erstellten tags werden in einem git-repo?

Question

Es wäre schön für unsere Jenkins CI-server automatisch zu erkennen, bereitstellen und erstellen von tags wie Sie erstellt werden, in unserem Github-repository.

Ist das möglich?

Answer 1

Mit der folgenden Konfiguration können Sie einen Job erstellen, der alle Tags erstellt:

1. Machen Sie die Job -Fetch -Tags so, als wären sie Zweige +refs/tags/*:refs/remotes/origin/tags/*
2. Lassen Sie es alle Tag "Zweige" mit dem Zweig -Spezifizierer erstellen */tags/*
3. Aktivieren Sie die SCM -Umfragen, damit der Job neue Tags erkennt.

Dieser Ansatz hat einen Nachteil: Der Job wird aufbauen alle Tags und nicht nur neu hinzugefügte Tags. Nachdem Sie den Job erstellt haben, wird er für jedes vorhandene Tag einmal ausgelöst. Wahrscheinlich möchten Sie wahrscheinlich zuerst nichts tun, dann warten Sie, bis alle vorhandenen Tags verarbeitet wurden, und konfigurieren Sie erst dann die Build -Schritte, die Sie für jedes neue Tag ausführen möchten.

Da sich die Tags in Git nicht ändern, wird der Job nur einmal für jedes neue Tag ausgelöst.

Answer 2

Um den Nachteil der Antwort von @oberlies zu überwinden, dass alle Tags gebaut werden, verwende ich stattdessen einen speziellen Auslöser Build. Der Trigger Build verwendet das gleiche Git -Repository und denselben Zweig wie der Hauptbau und die folgenden (Post-) Build -Schritte.

Build -> Shell ausführen:

# 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

Bauen -> Umgebungsvariablen injizieren:

Properties File Path: release.properties

Aktionen nach dem Bau ->: Auslösen parametrisierter Build auf anderen Projekten

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

Schließlich in Ihrem Hauptaufbau "Dieser Build ist parametrisiert" mit dem folgenden String -Parameter

Name: TAG
Default Value: <your release branch>

Und im Bereich "Quellcodeverwaltung" verwenden "$ tag" im Feld "Filialen zum Erstellen".

Answer 3

Sie können installieren ein post-receive hook, die überprüft, ob ein tag begangen, und erstellt ein build in jenkins.

Der Haken kann Aussehen etwas wie diese [*]:

#!/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())

[*] Hinweis:dies ist nur eine schnelle Umstellung von einer etwas anderen Skript, also ist es ziemlich wahrscheinlich, dass es einige kleine Fehler hier.Dies ist vor allem zu zeigen, die Idee.

Auf der jenkins-Seite, die Sie konfigurieren müssen Sie einen parametrisierten job.Der einzige parameter ist 'branch'.

1. Check 'dieser build ist parametrisiert' und fügen Sie den parameter
2. In " source code management -> Filialen zu bauen,' put '$branch'

Dies gibt eine ziemlich sichere und robuste Art und Weise zu bauen.Um zu testen, führen Sie einen build über das web-interface, es werden Fragen für die Wert der parameter.

Answer 4

In der Welt der modernen (?) Multi-Branch-Pipelines funktioniert das Aufbau von Tags wie folgt.

1. Fügen Sie das "Verhalten" hinzu, um Tags zu entdecken:
   
2. Verwenden Sie Plugin Grundlegende Strategien für die Erstellung von Branchen Fügen Sie eine "Build -Strategie" für Tags hinzu:Vergessen Sie nicht, auch eine Build -Strategie für Zweige hinzuzufügen. Das Plugin deaktiviert die Standardeinstellungen vollständig!

Answer 5

Sie können die Option "Git Publisher" verwenden, die als Teil der vorliegt Git -Plugin So erstellen Sie ein Tag nach einem erfolgreichen Build/Bereitstellung.