Как настроить отдельное задание Jenkins для выполнения процесса выпуска из основной ветви или веток?

В настоящее время я улучшаю процесс выпуска наших проектов на 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.
6. Как только это будет сделано, разработчик установил для версий pom.xml новую разрабатываемую версию (т. Е. 2.1-SNAPSHOT ).

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

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

Задания для новых выпусков

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

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

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

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

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

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

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

Спасибо.

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