Вопрос по git, jenkins – Плагин Jenkins Git: как создать определенный тег?

102

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

Вы имеете в виду, что это отличается отstackoverflow.com/questions/7157170/… ? (третий результатgoogle.com/…) VonC
Вы уверены, что хотите сделать это таким образом? Вы понимаете, чтоtagging in git doesn't scale? Может быть, вы могли бы просто использовать «выполнить оболочку»? Задача написать скрипт для проверки тега / ревизии выreally хочу? mpontillo
"Это заняло 3 часа моего дня" - Я не настолько ленив, что 3 часа моего дня не включали каждую ссылку, которую я мог найти в Google :) monkjack

Ваш Ответ

10   ответов
181

ветки для сборки":

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

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

Я не знаю, почему у этого нет больше +1. Эта запись в блоге erics-notes очень запутанная. Это просто и прекрасно работает. Благодарность Cody S
Работал отлично для меня. Спасибо. Мой параметр был назван RELEASE_TAG, поэтому я использовал теги / $ {RELEASE_TAG} в качестве значения для Спецификатора ветви. Wesley Womack
Когда я пытаюсь сделать то, что предлагается в этом ответе, каждый опрос хранилища запускает сборку. Журнал опроса git будет постоянно показывать, что «Последняя построенная ревизия» является ревизией тега, а «Последняя ревизия удаленной главы - это» ревизия новейшей версииHEAD. Кажется, логика плагина git сравнивает эти две ревизии, которые в моем репозитории являютсявсегд неравенство и, следовательно, новая сборка всегда запускается. Louis
@ monkjack - разве это не должен быть принятый ответ? Ben
Не могу заставить это работать. По какой-то причине не могу оформить заказ. Я получаю: «ОШИБКА: не удалось найти ревизию для сборки. Проверьте конфигурацию репозитория и филиала для этого задания. ' Я указываю теги / 3.0.1, я также пробовал * / tags / 3.0.1 Я подтвердил, что тег существует. lostintranslation
71

используя Jenkins CI v.1.555, плагин Git Client v.1.6.4 и плагин Git 2.0.4.

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

Убедитесь, что вы поместили свой тег в удаленный репозиторий с помощьюgit push --tags В разделе «Git Repository» своей работы под заголовком «Управление исходным кодом» нажмите «Дополнительно». В поле 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) и механизма push-уведомлений Git-репозитори Stash Webhook для Дженкинс: в любой моментлюбоетвь @ в хранилище обновляется одним нажатием, задания сборки тегов также запускаются снова. Это приводит к большому количеству ненужных повторных сборок одних и тех же заданий тегов снова и снова. Я попытался настроить задания как с опцией «Принудительное использование рабочей области», так и без нее, и, похоже, это не дало никаких результатов. Единственный способ помешать Дженкинсу создавать ненужные сборки для заданий тегов - это очистить поле Refspec (т.е. удалить символ+refs/tags/*:refs/remotes/origin/tags/*).

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

это должен быть принятый ответ! benny.la
Дополнительный +1 за это решение. Предыдущие решения у меня тоже не сработали. whitespy9
Чтобы «добавить следующий текст» в refspec ..., если ваш refspec был ранее+refs/heads/*:refs/remotes/origin/* теперь будет+refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/remotes/origin/tags/*. (Я мало работал с refspecs, поэтому потребовались некоторые эксперименты, чтобы понять, что это поле разделено пробелами.) hangtwenty
14

чтобы он строил по имени Ref? Если так, то это

refs/tags/tag-name

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

@ monkjack Я попробовал тот же синтаксис на одном из моих репо, и это сработало. Можете ли вы перечислить ваши текущие теги? Вы уверены, что специально добавили этот тег в удаленное хранилище с помощьюgit push --tags Andrew T Finnell
Приближаясь. Я не выдвигал метки к пульту, но теперь я. Я могу получить сборку jenkins сейчас, используя refs / tags / harpercollins-1.0.16, однако он всегда настаивает на сборке head независимо от того, что я туда вставил. Я подтвердил, что на пульте есть тег (его можно увидеть в gitweb), и создание снимка этого тега подтверждает, что там все правильно. monkjack
TeamCity является частной собственностью, что делает его практически бесполезным. slang
На самом деле ты не первый, кто предлагает город команды. Это действительно намного лучше? Я мог бы проверить это. monkjack
О да, переход с бесплатного инструмента на коммерческий - это правильный выбор! Когда реактивные мозги изобретут велосипед и создадут новую систему отслеживания ошибок, вы предложите другим переключиться с bugzilla на эту? m1ld
7

просто укажите имя тега в поле «Филиалы для построения». в параметризованной сборке вы можете использовать параметр как переменную в том же поле 'Branches to build', т.е. $ {Branch_to_build}. ты можешь установитьGit Parameter Plugin который предоставит вам функциональность путем перечисления всех доступных веток и тегов.
Это помогло мне в Jenkins 1.532.3, я только что указал версию тега (например,1.0.1) в ветках строить поле. andre
Спасибо за указатель на Git Parameter Plugin. Mark Larter
Indeed просто введя имя тега, работало и для меня. Хотя в документации к этому в плагине git все еще говорится, что выполнение этого не должно работать: "<tagName>: это не работает, поскольку тег не будет распознан как тег. Вместо этого используйте refs / tags / <tagName>." Zitrax
8

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

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

UPDATE APR-2018 - Обратите внимание в комментариях, что это работает для одного человека и соответствует документации Jenkins.

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

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

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
7

г (например: aTAG параметр вашей сборки), вот что вы можете сделать:

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
  }
}
3

установив для Refspec и Branch Specifier значение подробности в этом блоге.

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

2

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

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

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

Ты тоже можешь поставить галочку " Построить, когда изменение передается в GitHub ", чтобы вызвать толчок, но вы должны добавить"Создайте" действие к веб-крюку

1

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

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

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

Похожие вопросы