Возможно ли Дженкинс автоматически обнаружить и построить вновь созданные теги в git Repo?

Question

Было бы неплохо для нашего сервера Jenkins CI автоматически обнаружить, развернуть и создавать теги, поскольку они создаются в нашем репозитории GitHub.

Это возможно?

Answer 1

С помощью следующей конфигурации вы можете сделать работу построить все теги:

1. Сделайте теги, как будто они были ветвями: нажмите кнопку «Дополнительно» под URL -адресом репозитория и введите RefSpec +refs/tags/*:refs/remotes/origin/tags/*
2. Сделайте его построить все теги «ветви» со спецификатором ветви */tags/*
3. Включите опрос SCM, чтобы задача обнаруживала новые теги.

Этот подход имеет один недостаток: работа построит все Теги, а не только недавно добавленные теги. Таким образом, после того, как вы создали работу, она будет запускается один раз для каждого существующего тега. Таким образом, вы, вероятно, захотите, чтобы работа не сделала ничего не делать сначала, а затем подождите, пока все существующие теги не будут обработаны, и только затем настройка шагов сборки, которые вы хотите сделать для каждого нового тега.

Поскольку теги не изменяются в GIT, задание будет затем инициировано только один раз для каждого нового тега.

Answer 2

Чтобы преодолеть недостаток ответа @overlies, что все теги будут построены, я использую специальную сборку триггера. Сборка триггера использует тот же репозиторий GIT и ветвь, что и основная сборка, и следующие шаги сборки (после).

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 -> Вводные переменные среды:

Properties File Path: release.properties

Пост -сборщики ->:: Запустите параметризованную сборку на другие проекты

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

Наконец, в вашей основной сборке тик «Эта сборка параметризована» со следующим параметром строки

Name: TAG
Default Value: <your release branch>

И в разделе «Управление исходным кодом» используйте «$ Tag» в поле «Ветви для строительства».

Answer 3

Вы можете установить крюк с пост-получением, который проверяет, был ли отмечен тег, и создает сборку в Дженкинсе.

Крюк может выглядеть примерно так [*]:

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

*] Примечание: это просто быстрое преобразование из немного другого сценария, поэтому вполне вероятно, что здесь есть несколько небольших ошибок. Это в основном, чтобы показать эту идею.

На стороне Дженкинса вам необходимо настроить параметризованную работу. Единственный параметр - «ветвь».

1. Проверьте «Эта сборка параметризована» и добавьте параметр
2. В «Управление исходным кодом» -> филиалы для создания «Поместите« филиал $ »

Это дает довольно надежный и надежный способ построения. Чтобы проверить, запустите сборку через веб -интерфейс, он попросит значение параметра.

Answer 4

В мире современных (?) Многоразмерных трубопроводов строительные бирки работают следующим образом.

1. Добавьте «поведение», чтобы обнаружить теги:
   
2. Используйте плагин Основные стратегии сборки филиала Чтобы добавить «стратегию сборки» для тегов:Не забудьте добавить стратегию сборки и для филиалов; Плагин полностью отключает по умолчанию!

Answer 5

Вы можете использовать опцию «GIT Publisher», которая поступает как часть GIT плагин Чтобы создать тег после успешной сборки/развертывания.