Как настроить одно задание Jenkins, чтобы сделать процесс освобождения от магистрали или ветвей?

Question

В настоящее время я улучшаю процесс выпуска наших проектов в Jenkins (1.430).

Текущие задания по выпуску

Сегодня для одного конкретного проекта у нас есть одинработа, посвященная процессу выпуска.Полная процедура такова:

1. Разработчик, отвечающий за выпуск, вручную меняет версию всех файлов pom.xml (фактически используя mvn versions:set -DnewVersion=2.0), чтобы избавиться от -SNAPSHOT.
2. Затем он создает тег в SVN (например, http://my -svn-repo / project / tags / V_2_0 ).
3. После этого тегабыл создан, он входит на наш сервер Jenkins и запускает сборку Release.
4. Эта сборка спросит его, какой тег он хочет использовать для сборки.Задание настроено как Параметризованная сборка с параметром Список Subversion-тегов .
5. Затем Дженкинс создаст артефакты из этого тега и развернет их на нашем Nexus.instance.
6. Как только это будет сделано, разработчик установил версии pom.xml для новой версии разработки (т.е. 2.1-SNAPSHOT).

Преимущество этого метода заключается в том, что яесть только задание Jenkins, поскольку сборка будет опираться только на тег.

Однако эта процедура включает слишком много вмешательств человека (изменения pom.xml, commitits, tags и т. д.).

Новые задания релиза

Теперь я использую плагин релиза Maven.Я создал задание, которое запрашивает у пользователя, запускающего сборку, три информации:

• версия релиза (параметр releaseVersion плагина релиза);
• версия разработки, после выпуска (параметр developmentVersion плагина релиза);
• имя тега (параметр tag плагина релиза).

Thisзадание работает нормально, за исключением одного момента: задание основано на соединительной линии или ветви в SVN.Это означает, что если у меня есть 2 ветви (в дополнение к стволу), мне нужно будет создать 3 задания релиза: по одному на ветку.

Одна идея, чтобы сохранить лучшее из двух миров (то есть, используя релиз mvn, но сохраняя 1 выпуск релиза) это добавить параметр сборки, который будет запрашивать у пользователя путь к стволу / ветви.Поэтому вместо настройки http://my-svn-repo/project/trunk (или http://my-svn-repo/project/branches/BRANCH_V1) в конфигурации задания я установлю http://my-svn-repo/project/$FROM_BRANCH и попросу пользователя ввести параметр FROM_BRANCH.

Проблема этого решения заключается в том, чтопользователь должен будет ввести либо trunk, либо branches/BRANCH_Vx, что может привести к ошибкам.

В идеале мне бы хотелось иметь параметр сборки, который позволил бы мне выбрать ветвь (включая ствол),в качестве параметра список Subversion тегов существует для выбора тегов ...

Поэтому мой вопрос: есть ли лучший способ настроить одну работу Jenkins, которая может работатьна всех ветках?

Спасибо.

Редактировать : Я обнаружил плагин Jenkins для Validating String , который может быть интересен, чтобы гарантировать, что значение, определенное пользователем, уважает некоторое регулярное выражение.Это полезно в моем случае ...

Answer 1

Просто добавьте некоторые примечания к ответу Питера, если вы не очень знакомы с Дженкинсом.

Плагин Subversion установлен по умолчанию в последних версиях (по состоянию на сентябрь 2015 года).

Тогда вы должны настроить свой проект следующим образом:

1. отметьте «Эта сборка параметризована» (этот проект параметризован в новейших версиях)
2. выберите «Список тегов subverion (и более)»
3. в поле имени установите переменное имя, на которое можно ссылаться позже в URL-адресе svn. Я выбираю svnbranch здесь.
4. в поле URL-адрес хранилища укажите его URL-адрес проекта (который должен содержать ствол, ветви и теги)
5. заполните другие поля по мере необходимости
6. в управлении исходным кодом, обратитесь к переменной, определенной ранее в URL вашего репозитория.

проверьте следующие скриншоты:

Answer 2

Вам нужна версия 1.32 плагина Subversion. В этой версии был реализован выпуск JENKINS-10678 .

Затем вы даете ему только URL своего проекта (который должен содержать ствол, ветви и теги), и он предложит вам ствол вместе с вашими ветвями.