Плагин релиза Hudson/Jenkins: выпуск версии выпусков

Question

Я собираюсь создать новый проект hudson и наткнулся на release plugin. У вас есть в основном две возможности:

1. Не задаем строку параметров releaseVersion и developmentVersion - то плагин релиз Maven использует значения по умолчанию. (Версия 1.0.0-SNAPSHOT (svn) -> 1.0.0 будет выпущена (тег в svn) и 1.0.1-SNAPSHOT будет следующей версией разработки.) В большинстве случаев этого достаточно для нас. Однако в некоторых случаях (например, основной выпуск должен быть создан) этого недостаточно.
2. Определите эти два значения (cp. Image, red markers), но тогда вы всегда должны их заполнять, и они пусты! Очевидно, что нет возможности использовать значения по умолчанию или оставить их пустыми. Вот почему есть возможность добавить preRelease и postRelease действия, подобные скриптам и т. Д. Однако, если плагин будет немного более интеллектуальным, что не понадобится имхо.

Так что мой вопрос: Есть ли способ без использования до/после сборки выпуска скриптов, чтобы получить желаемое поведение?

Желаемое поведение: поля releaseVersion и developmentVersion должны быть предварительно заполнены фактической версией/версией + 1. Если это невозможно, оставляя эти поля пустыми, также достаточно (если это вызывает поведение по умолчанию для плагина maven build). Если эти поля теперь пустые, maven будет вызываться с пустым параметром и, следовательно, сбой.

(В разных проектах я использовал jenkins в сочетании с плагином для выпуска artifactory, который очень прост - если версия должна быть выпущена, страница показывает, где указаны все версии. Если, например, основная версия должна быть построена пользователь может легко изменить номера.)

Answer 1

У меня была аналогичная проблема, но решение для меня может иметь некоторые значительные накладные расходы в вашей ситуации.

Работа в моей настройке не создается вручную, а создается с использованием Job DSL Plugin. Это связано с тем, что существует множество подобных работ для разных артефактов, и поколение стремится прекратить работу снежинок у разных пользователей.

Мое решение выглядит примерно так:

1. Для каждого задания в поколение: Query ваше хранилище артефактов для последней версии артефакта, созданного задания (Sonatype Nexus для меня)
2. Сформировать версии вы хотите отобразить пользователь (просто добавить второстепенные и т.д.)
3. Нанести версию, как по умолчанию-текст для вашего строкового параметра в работе DSL (как показано here)
4. Rerun поколение в заданном интервале, поэтому рабочие места, скорее всего, шо w правильные версии

Это было легко для меня, поскольку Job DSL уже был на месте, и имя каждого артефакта является частью имени задания. Это далеко не идеально, поскольку во времени могут быть моменты, которые не показывают правильную версию (сразу после новой версии, когда создание задания не было повторно запущено).

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

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