Как обеспечить тот же git checkout для создания и развертывания рабочих мест в Jenkins?

В Jenkins у меня есть настройка «Build» для опроса моего git-репо и автоматического построения изменений. Затем у меня есть отдельные задания «Deploy to DEV», «Deploy to QA» и т. Д., Которые вызывают сборку Ant, которая развертывается соответствующим образом. В настоящее время эта конфигурация отлично работает.Как обеспечить тот же git checkout для создания и развертывания рабочих мест в Jenkins?

Однако этот процесс способствует развертыванию последней сборки на последней ветке разработки. Я использую плагин Copy Artifact, чтобы позволить пользователю выбирать, какую сборку нужно развернуть. Кроме того, скрипты Ant для сборки/развертывания являются частью репо и могут быть изменены. Это означает, что артефакт может быть несовместимым между версиями. Таким образом, идеально, что я гарантирую, что задания сборки и развертывания выполняются с использованием той же самой проверки git.

Есть ли более простой способ? Должно быть возможно, чтобы задание Deploy получало хэш-код git, используемый из выбранной сборки и проверки. Тем не менее, я не вижу никаких параметров или плагинов, которые это делают.

Любые идеи о том, как упростить эту конфигурацию?

источник

2014-01-15 spoulson

Вы можете использовать Parameterized Trigger Plugin, чтобы сделать это за вас. Прямым способом является подготовка файла с параметрами в качестве шага сборки и передача этих параметров в задание ниже по течению с помощью плагина. Вы можете передать git-версию в качестве параметра, например, или других параметров.

источник

2014-01-15 18:16:56 ScayTrase

Я не хочу запускать автоматическое развертывание. Например, мне нужно вернуть Dev в устаревшую версию. Я запустил задание Deploy, укажите номер сборки как параметр «Сборка селектора для копирования артефакта». Копировать артефакт вытягивает соответствующий артефакт. Однако задание не знает автоматически переключиться на git-ревизию, в которой был создан артефакт. Так что теперь у меня есть параметр GitBranch, где я указываю соответствующую ветку. На самом деле я хотел бы исключить параметр GitBranch. Он должен уже знать пересмотр из сборки. – spoulson

таким образом вы можете добавить некоторые файлы конфигурации в свой набор артефактов. Чем вы можете использовать их, чтобы сообщить git, какая версия принадлежит извлеченному артефакту – ScayTrase

Я вижу, но как вы получаете задание Копировать артефакты (чтобы получить этот файл свойств) и прочитать файл свойств перед git checkout? Проверка происходит до каких-либо шагов сборки. – spoulson

Детали могут отличаться для Git repo (см. https://stackoverflow.com/a/13117975/466874), но для наших заданий на основе SVN мы делаем задание сборки (re) для создания тега SVN (со статическим именем, таким как «LatestSuccessfulBuild») при успешном завершении, а затем мы настраиваем задания развертывания, чтобы использовать этот тег в качестве своего URL-адреса репо, а не местоположение соединительной линии. Это гарантирует, что развертывания всегда будут независимо от того, какая версия была успешно построена заданием сборки (что означает, что все переданные модульные тесты и т. Д.) Вместо того, чтобы разрешать новые транзакции магистрали проникать в сборку развертывания.

источник

2014-10-03 16:44:15

Как обеспечить тот же git checkout для создания и развертывания рабочих мест в Jenkins?

ответ

Смежные вопросы