Вопрос по git, jenkins – Плагин Jenkins Git: как создать определенный тег?
У меня проблемы с получением Jenkins для создания указанного тега. Тег является частью параметризованной сборки, но я не знаю, как передать это плагину git, чтобы просто построить этот тег. Это заняло 3 часа моего дня, и я уступил поражение мастерам при переполнении стека.
ветки для сборки":
Branch Specifier (blank for default): tags/[tag-name]
Замените [имя-тега] именем вашего тега.
HEAD
. Кажется, логика плагина git сравнивает эти две ревизии, которые в моем репозитории являютсявсегд неравенство и, следовательно, новая сборка всегда запускается.
используя 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 после успешного выполнения задания.
+refs/heads/*:refs/remotes/origin/*
теперь будет+refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/remotes/origin/tags/*
. (Я мало работал с refspecs, поэтому потребовались некоторые эксперименты, чтобы понять, что это поле разделено пробелами.)
чтобы он строил по имени Ref? Если так, то это
refs/tags/tag-name
Из всех вопросов, которые я вижу о Дженкинсе и Хадсоне, я бы предложил перейти на TeamCity. Мне не пришлось редактировать конфигурацию, файлы, чтобы заставить TeamCity работать.
git push --tags
просто укажите имя тега в поле «Филиалы для построения». в параметризованной сборке вы можете использовать параметр как переменную в том же поле 'Branches to build', т.е. $ {Branch_to_build}. ты можешь установитьGit Parameter Plugin который предоставит вам функциональность путем перечисления всех доступных веток и тегов.
1.0.1
) в ветках строить поле.
refs/tags/[your tag name]
. Это кажется проще, чем различные другие предложения для Refspec, но у меня все получилось.
ОБНОВЛЕНИЕ 23/7/2014 - На самом деле, после дальнейшего тестирования выясняется, что это не сработало, как ожидалось. Похоже, что версия HEAD все еще проверяется. Пожалуйста, отмените это как принятый ответ. В итоге я получил рабочее решение, следуя сообщению от Gotgenes в этомнит (30 марта). Проблема, упомянутая в этом посте о ненужном запуске сборок, не была для меня проблемой, так как моя работа вызвана работой из основной ветки разработки, а не опросом SCM.
UPDATE APR-2018 - Обратите внимание в комментариях, что это работает для одного человека и соответствует документации Jenkins.
refs/tags
префикс и просто используйте<tagname>
. YMMV, но ... он отлично работает для моих целей.
refs/tags/<tagname>
это то, что документация Дженкинса Говорит должен быть использован, и он работает нормально для меня. Возможно, плагин был глючным во время первоначального поста, но ... по состоянию на апрель 2018 года, этотявляетс правильный ответ
Я сделал что-то вроде этого, и это сработало:
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
был трюк, нажав кнопку Дополнительно.
установив для Refspec и Branch Specifier значение подробности в этом блоге.
Мне также пришлось установить имя репозитория (в моем случае «origin»), чтобы я мог ссылаться на него в Refspec (иначе он, очевидно, использовал бы случайно сгенерированное имя).
создал новую ветку
jenkins-target
и заставил Дженкинса отследить это слияние с той веткой или тегом, которые я хочу построить наjenkins-target
раз сборка работала, тесты проходили и т.д., просто создай тег изjenkins-target
веткЯ не уверен, что это сработает для всех, мой проект был довольно маленьким, не слишком много тегов и прочего, но его было очень легко сделать, не нужно возиться с refspecs, параметрами и прочим: -)