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

Ответ 1

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

• Сделать тегами выборки заданий, как если бы они были ветвями: нажмите кнопку "Дополнительно" под URL-адресом репозитория и введите Refspec +refs/tags/*:refs/remotes/origin/tags/*
• Создайте ли все теги "ветки" с помощью спецификатора Branch */tags/*
• Включить опрос SCM, чтобы задание обнаруживало новые теги.

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

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

Ответ 2

Чтобы преодолеть недостаток ответа @oberlies, что все теги будут построены, я вместо этого использую специальную триггерную сборку. Триггерная сборка использует тот же репозиторий git и ветвь как основной сборку и следующие шаги (post).

Сборка → Выполнить оболочку:

# 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

Сборка → Вводные переменные среды:

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" в поле "Филиалы для сборки".

Ответ 3

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

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

#!/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: это просто быстрое преобразование из немного отличающегося script, поэтому вполне вероятно, что здесь есть некоторые небольшие ошибки. Это в основном, чтобы показать эту идею.

На стороне jenkins вам нужно настроить параметризованное задание. Единственным параметром является "ветвь".

• Отметьте 'эта сборка параметризованной' и добавьте параметр
• В 'управлении исходным кодом → ветки для построения' put '$ branch'

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

Ответ 4

Вы можете использовать опцию "Git Publisher", которая входит в состав Git Plugin, чтобы создать тег после успешного построить/развернуть.