У меня возникают проблемы с созданием Jenkins для создания указанного тега. Тег является частью параметризованной сборки, но я не знаю, как передать это через плагин git, чтобы просто создать этот тег. Это заняло 3 часа моего дня, и я упустил поражение мастерам при переполнении стека.
Jenkins Git Плагин: как создать конкретный тег?
Ответ 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
Журнал 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 и выше) вы можете:
- просто укажите имя тега в поле "Филиалы для построения".
- в параметризованной сборке вы можете использовать параметр как переменную в том же поле 'Branches to build', т.е. $ {Branch_to_build}.
- Вы можете установить 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
- выберите опцию "строить с параметрами".
- добавить значение в поле как "refs/tags/tag_142" (tag_name = tag_142 для моего примера)