Jenkins Git Плагин: как создать конкретный тег?

У меня возникают проблемы с созданием Jenkins для создания указанного тега. Тег является частью параметризованной сборки, но я не знаю, как передать это через плагин git, чтобы просто создать этот тег. Это заняло 3 часа моего дня, и я упустил поражение мастерам при переполнении стека.

Ответы

Ответ 1

Я смог сделать это, используя параметр "ветки для сборки":

Branch Specifier (blank for default): tags/[tag-name]

Замените [tag-name] на имя вашего тега.

Ответ 2

Ни один из этих ответов не был достаточным для меня, используя Jenkins CI v.1.555, Git Клиентский плагин v.1.6.4 и Git плагин 2.0.4.

Мне нужно, чтобы задание создавалось для одного репозитория Git для одного определенного, фиксированного (т.е. непараметрированного) тега. Мне пришлось собрать решение из различных ответов, а "создать тег Git" цитируется Thilo.

  • Удостоверьтесь, что вы нажимаете свой тег в удаленный репозиторий с помощью git push --tags
  • В разделе "Git Репозиторий" вашего задания в разделе "Управление исходным кодом" нажмите "Дополнительно".
  • В поле Refspec добавьте следующий текст: +refs/tags/*:refs/remotes/origin/tags/*
  • В разделе "Филиалы для сборки", "Спецификатор ветвей", поставьте */tags/<TAG_TO_BUILD> (заменив <TAG_TO_BUILD> на ваше фактическое имя тега).

Добавление Refspec для меня оказалось критическим. Хотя казалось, что хранилища Git извлекали всю удаленную информацию по умолчанию, когда я оставил ее пустой, плагин Git, тем не менее, полностью не смог бы найти мой тег. Только когда я явно указал "получить удаленные теги" в поле Refspec, был плагин Git, способный идентифицировать и строить из моего тега.

Обновление 2014-5-7. К сожалению, это решение действительно связано с нежелательным побочным эффектом для Jenkins CI (v.1.555) и механизма уведомления о выпуске репозитория Git à la Stash Webhook для Jenkins: всякий раз, когда какая-либо ветка в репозитории обновляется в push, задания создания тегов снова срабатывают. Это приводит к множеству ненужных повторных построений одних и тех же тегов снова и снова. Я попытался настроить задания как с параметром "Force polling using workspace", так и без него, и это, казалось, не имело никакого эффекта. Единственный способ, которым я мог помешать Дженкинсу сделать ненужные сборки для заданий тегов, - очистить поле Refspec (т.е. Удалить +refs/tags/*:refs/remotes/origin/tags/*).

Если кто-то найдет более элегантное решение, отредактируйте этот ответ с обновлением. Я подозреваю, например, что, возможно, этого не произойдет, если refspec определенно был +refs/tags/<TAG TO BUILD>:refs/remotes/origin/tags/<TAG TO BUILD>, а не только звездочкой. На данный момент, однако, это решение работает для нас, мы просто удаляем дополнительный Refspec после успешного выполнения задания.

Ответ 3

Не могли бы вы рассказать Дженкинсу построить из имени Ref? Если это так, то

refs/tags/tag-name

Из всех вопросов, которые я вижу о Дженкинсе и Хадсоне, я бы предложил перейти на TeamCity. Мне не пришлось редактировать файлы конфигурации, чтобы заставить TeamCity работать.

Ответ 4

Я сделал что-то вроде этого, и это сработало:

Source Code Management

 Git    
    Repositories    


 Advance

Name: ref
Refspec : +refs/tags/*:refs/remotes/origin/tags/* 

 Branches to build  
 Branch Specifier (blank for 'any') : v0.9.5.2

enter image description here

Журнал Jenkins подтвердил, что он получал источник из тега

Проверка версии 0b4d6e810546663e931cccb45640583b596c24b9 (v0.9.5.2)

Ответ 5

Если вы используете конвейеры Jenkins и хотите проверить конкретный тег (например: a TAG параметр вашей сборки), вот что вы можете сделать:

stage('Checkout') {
  steps {
    checkout scm: [$class: 'GitSCM', userRemoteConfigs: [[url: 'YOUR_GIT_REPO_URL.git', credentialsId: 'YOUR_GIT_CREDENTIALS_ID' ]], branches: [[name: 'refs/tags/${TAG}']]], poll: false
  }
}

Ответ 6

Я установил для поля Advanced-> Refspec значение refs/tags/[your tag name]. Это кажется проще, чем различные другие предложения для Refspec, но для меня это работало просто отлично.

ОБНОВЛЕНИЕ 23/7/2014 - На самом деле, после дальнейшего тестирования выясняется, что это не сработало, как ожидалось. Похоже, что версия HEAD все еще проверяется. Пожалуйста, отмените это как принятый ответ. В итоге я получил рабочее решение, следуя сообщению от gotgenes в этой теме (30 марта). Упомянутая в этом посте проблема ненужного запуска сборок не была для меня проблемой, так как моя работа вызвана работой из основной ветки разработки, а не опросом SCM.

ОБНОВЛЕНИЕ APR-2018 - обратите внимание в комментариях, что это работает для одного человека, и согласен с документацией Jenkins.

Ответ 7

В последней версии Jenkins (1.639 и выше) вы можете:

  1. просто укажите имя тега в поле "Филиалы для построения".
  2. в параметризованной сборке вы можете использовать параметр как переменную в том же поле 'Branches to build', т.е. $ {Branch_to_build}.
  3. Вы можете установить Git Parameter Plugin, который предоставит вам функциональность, перечислив все доступные ветки и теги.

Ответ 8

Мне удалось заставить Jenkins создать тег, установив Refspec и Branch Specifier как подробно в этом сообщении в блоге.

Мне также пришлось установить имя репозитория (в "происхождение" в моем случае), чтобы я мог ссылаться на него в Refspec (иначе он, по-видимому, использовал бы произвольно сгенерированное имя).

Ответ 9

В конце концов я сделал следующее:

  • создал новую ветвь jenkins-target, и получил jenkins для отслеживания того, что
  • сливается из какой-либо ветки или метки, которую я хочу построить на jenkins-target
  • После того, как сборка работала, проверялась передача и т.д., просто создайте тег из ветки jenkins-target

Я не уверен, что это будет работать для всех, мой проект был довольно маленьким, не слишком много тегов и всего, но он мертв легко сделать, не нужно возиться с refspecs и параметрами и т.д.: -)

Ответ 10

Вы можете создать даже тип тега, например 1.2.3-alpha43, используя подстановочные знаки:

Refspec: +refs/tags/*:refs/remotes/origin/tags/*

Спецификатор ветвления: origin/tags/1.2.3-alpha*

Вы также можете пометить "Сборка, когда изменение переместится в GitHub", чтобы вызвать push, но вам нужно добавить "создать" действие к веб-хосту

Ответ 11

Добавляю свои два цента здесь, так как я не видел ответа, который использует опцию "Построить с параметрами" в Jenkins.

Здесь я использую консоль браузера Jenkins CI для проекта starwars_api, и мне удалось собрать напрямую с помощью "Построить с параметрами" со значением refs/tags/tag-name

  1. выберите опцию "строить с параметрами".
  2. добавить значение в поле как "refs/tags/tag_142" (tag_name = tag_142 для моего примера)

введите описание изображения здесь