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


121

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


Вы имеете в виду, что это отличается от stackoverflow.com/questions/7157170/… ? (третий результат google.com/… )
VonC

1
«Это занимает 3 часа моего дня» - я не такой ленивый, что 3 часа моего дня не включали все ссылки, которые я мог найти в Google :)
sksamuel

1
Вы уверены, что хотите сделать это так? Вы понимаете, что теги в git не масштабируются ? Может быть, вы могли бы просто использовать задачу «выполнить оболочку», чтобы написать сценарий, чтобы проверить тег / версию, которую вы действительно хотите?
mpontillo

Ответы:


223

Я смог сделать это с помощью параметра «ветви для создания»:

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

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


5
Я не знаю, почему здесь не больше +1. Эта запись в блоге erics-notes чертовски сбивает с толку. Это просто и отлично работает. Спасибо!
Cody S

3
Отлично сработал для меня. Спасибо. Мой параметр был назван RELEASE_TAG, поэтому я использовал теги / $ {RELEASE_TAG} в качестве значения для спецификатора ветвления.
Wesley Womack

3
Не удалось заставить это работать. По какой-то причине не могу проверить тег. Я получаю: «ОШИБКА: не удалось найти версию для сборки. Проверьте конфигурацию репозитория и ветки для этого задания ». Я указываю теги / 3.0.1, я также пробовал * / tags / 3.0.1 Я проверил, что тег действительно существует.
lostintranslation

1
Когда я пытаюсь сделать то, что предлагается в этом ответе, каждый опрос репозитория запускает сборку. Журнал опроса git будет постоянно показывать, что «Последняя созданная ревизия» - это ревизия тега, а «Последняя ревизия удаленной головки» - это ревизия самой новой HEAD. Логика плагина git, кажется, сравнивает эти две ревизии, которые в моем репозитории всегда не равны, и поэтому всегда запускается новая сборка.
Луи

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

76

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

Я хотел создать задание для одного репозитория Git для одного конкретного фиксированного (т. Е. Не параметризованного) тега. Мне пришлось сколотить решение из различных ответов плюс сообщение в блоге «создать тег Git», цитируемое Тило .

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

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

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

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


4
Чтобы «добавить следующий текст» в refspec ... если ваш refspec был ранее, +refs/heads/*:refs/remotes/origin/*то теперь он будет +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/remotes/origin/tags/*. (Я не очень много работал с refspecs, поэтому потребовались некоторые эксперименты, чтобы узнать, что это поле разделено пробелами.)
driftcatcher

1
Дополнительный +1 за это решение. Предыдущие решения тоже не помогли мне.
whitespy9

16

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

refs/tags/tag-name

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


На самом деле, вы не первый, кто предлагает город команды. Неужели все намного лучше? Я могу это проверить.
sksamuel

1
@monkjack Я попробовал тот же синтаксис в одном из своих репо, и он сработал. Вы можете перечислить свои текущие теги? Вы уверены, что специально разместили этот тег в удаленном репо с помощьюgit push --tags
Эндрю Т. Финнелл

4
Все ближе. Я не подталкивал теги к удаленному, но теперь я это делаю. Я могу заставить Дженкинса построить сейчас, используя refs / tags / harpercollins-1.0.16, однако он всегда настаивает на создании головы, независимо от того, что я туда вставляю. Я подтвердил, что на пульте дистанционного управления есть тег (его можно увидеть в gitweb), и создание снимка этого тега подтверждает, что все в нем правильно.
sksamuel

6
TeamCity проприетарный, что делает его бесполезным.
сленг

2
Ах да, переход с бесплатного инструмента на коммерческий - правильный выбор! Когда Jetbrains изобретут велосипед и создадут новый трекер ошибок, предложите ли вы другим перейти с bugzilla на это?
m1ld 02

11

Если вы используете конвейеры Jenkins и хотите проверить определенный тег (например: 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
  }
}

9

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

  1. просто укажите название тега в поле «Отрасли для построения».
  2. в параметризованной сборке вы можете использовать параметр как переменную в том же поле «Ветви для сборки», то есть $ {Branch_to_build}.
  3. вы можете установить подключаемый модуль Git Parameter, который предоставит вам функциональность, перечислив все доступные ветки и теги.

1
Действительно, просто ввод имени тега у меня тоже сработал. Хотя в документации по этому вопросу в подключаемом модуле
Zitrax

Это сработало для меня в Jenkins 1.532.3, я просто указал версию тега (например 1.0.1) в поле веток для сборки.
andre

9

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

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)


Это отлично подходит для создания всех тегов, спасибо! Добавление refspecбыло уловкой, нажав кнопку «Дополнительно».
Styfle

9

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

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

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


Просто хотел отметить, что через четыре года после того, как этот ответ был опубликован, использование refs/tags/<tagname>- это то, что сказано в документации Jenkins , и у меня это работает нормально. Возможно , плагин был багги в момент первоначального поста, но ... по состоянию на апрель 2018 года, это является правильным ответом.
evadeflow

Обновление моего предыдущего комментария: На самом деле я обнаружил, что могу опустить refs/tagsпрефикс и просто использовать <tagname>. YMMV, но ... он отлично подходит для моих целей.
evadeflow

3

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

Мне также пришлось установить имя репозитория (в моем случае «origin»), чтобы я мог ссылаться на него в Refspec (в противном случае он явно использовал бы случайно сгенерированное имя).


2

В итоге я сделал следующее:

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

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


Мне нравится этот очень простой подход.
zochhuana

2

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

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

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

Вы также можете установить флажок « Строить, когда изменение отправлено на GitHub », чтобы инициировать отправку, но вы должны добавить действие «создать» в веб-перехватчик.


1

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

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

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

построить с именем тега ref

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.