Использование переменной, полученной с помощью команды оболочки перед сборкой, для установки опции для сборки Maven в Hudson - PullRequest
0 голосов
/ 02 сентября 2010

У меня есть работа в Хадсоне, которая ставит перед собой цель.Перед выполнением этой maven цели я добавил шаг для запуска перед началом сборки, это сценарий оболочки, который получает номер версии, который я хочу использовать в поле «Цели и параметры».

Итак, вмоя конфигурация задания в Среда сборки Я установил Настроить дополнительные шаги сборки M2 и добавил сценарий оболочки перед сборкой.Сценарий выглядит так:

export RELEASE={command to extract release version}
echo $RELEASE

А затем в разделе Build я указываю на мой «корневой pom».В Цели и параметры я хочу иметь возможность сделать что-то вроде этого:

-Dbuild.release.version=${RELEASE} deploy

Где build.release.version - это свойство maven, на которое ссылаются вПОМ.Однако, поскольку оболочка, кажется, не делает свои переменные глобальными, она не работает.Любые идеи?

Единственное, что у меня есть, это установить плагин Envfile и получить скрипт оболочки для записи свойства RELEASE в файл, а затем получить плагин для чтения файла,но порядок, в котором все выполняется, может вызвать проблемы, и кажется, что должен быть более простой способ ... есть?

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 25 мая 2011

Я недавно хотел сделать то же самое, но AFAIK невозможно экспортировать значения из оболочки перед сборкой в ​​рабочую среду. Если для этого есть плагин Hudson, то я его пропустил.

Однако сработала установка, аналогичная той, которую вы предлагали: предварительно подготовив сценарий оболочки для записи, записать желаемые значения в файл свойств в рабочей области, а затем с помощью параметра Parametrized. Плагин Trigger для запуска другой работы, которая фактически выполняет эту работу (в вашем случае вызовите работу Maven). Плагин может быть настроен на чтение параметров, которые он передает из файла свойств. Таким образом, у задания first есть только сценарий оболочки и триггеры после сборки, а second выполняет реальную работу, имея правильные параметры, доступные в качестве переменных среды.

Общая идея сценария оболочки:

echo "foo=bar
baz=`somecmd`" > build.properties

А для ваших целей и вариантов, что-то вроде:

-Dbuild.release.version=${foo} deploy

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

0 голосов
/ 03 сентября 2010

Когда вы говорите, что это не работает, вы имеете в виду, что ваша переменная RELEASE не передается команде maven?Я считаю, что проблема в том, что по умолчанию каждая строка скрипта оболочки выполняется отдельно, поэтому переменные среды теряются.

Если вы хотите, чтобы весь скрипт оболочки выполнялся так, как если бы это был один файл скрипта, сделайтепервая строка:

#!/bin/sh

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

...