У меня есть работа Maven в Дженкинсе. Перед фактическим этапом сборки у меня есть шаг предварительной сборки "Выполнение оболочки". В этой оболочке я устанавливаю переменную:
REVISION=$(cat .build_revision)
Я хотел бы использовать эту переменную в задании сборки Maven в "Цели и параметры":
clean install -Drevision=${REVISION}
Но это не работает! "Drevision" установлен на "$ {REVISION}", а не на фактическое значение ${REVISION}. Выход:
Executing Maven: -B -f /home/gerrit/.jenkins/jobs/<job_name>/workspace/pom.xml clean install -Drevision=${REVISION}
Он работает с переменными окружения Jenkins:
clean install -Dbuild=${BUILD_NUMBER}
Он устанавливает "Dbuild" в фактический номер сборки. Выход:
Executing Maven: -B -f /home/gerrit/.jenkins/jobs/<job_name>/workspace/pom.xml clean install -Dbuild=54
Мой вопрос: как использовать переменную оболочки в Maven "Цели и параметры"?
EDIT:
Я попытался использовать Jenkins EnvInject Plugin для "Внедрить переменные среды" после оболочки pre-build, и моя переменная теперь доступна, например, post-build shells, но он по-прежнему недоступен в Maven "Цели и параметры".
Затем можно установить "Инъекционные переменные среды для процесса сборки" с помощью EnvInject Plugin, что фактически делает эти переменные доступными в Maven "Цели и параметры", но они устанавливаются сразу после проверки SCM, строить шаги и не поддерживать оценки выражений.
Вы на правильном пути здесь, но пропустили третью функцию EnvInject-Plugin: шаг сборки "Inject environment variables", который может вставлять переменные в следующие шаги сборки на основе результата script или свойств,
Мы используем плагин EnvInject именно так; A script устанавливает ресурс и передает его параметры с использованием свойств, которые затем распространяются плагином как переменные среды.
то есть. создание временной базы данных для сборки:
У меня была очень похожая проблема, пытаясь вычислить версию сборки и вставить ее в сборку. После того, как вы столкнулись со всеми теми же проблемами (не расширяя и т.д.), Я использовал параметр "Создать переменные среды из script", который интерпретирует результат как пары tag = value в переменных Jenkins. script:
#generate a version code that is high enough to surpass previously published clients
val=`expr 150000 + $BUILD_NUMBER`
echo VERSION_CODE=$val
После этого мне удалось ввести $VERSION_CODE в maven следующим образом:
-Dbuild.vercode=${VERSION_CODE}
Надеюсь, что это сработает для вас.
Эта проблема вызвана ошибкой в проекте Jenkins Maven Project Plugin, как описано в этот отчет об ошибках открыт в 2012-06-22. Плагин еще не исправлен с версии 2.1.
Исправление было предложено для плагина Maven Project, но еще не интегрировано. Вот ссылка на запрос на pull: https://github.com/jenkinsci/maven-plugin/pull/14
Если вы создаете плагин самостоятельно с применением патча запроса на перенос, переменные вводятся и становятся доступными для поля "цели и параметры", как ожидалось.
Я думаю, что ваш лучший снимок - попробовать EnvInject плагин для этого вместе с вашим начальным шагом до scm.
Рассмотрите возможность загрузки содержимого вашего файла (формата свойств) или выполните script, который будет загружать файл по вашему желанию и сделать переменную доступной для остальной части задания с помощью "Подготовьте среду для запуска",.
Надеюсь, это поможет.
Я вижу, что есть принятый ответ, но для новичков в Дженкинсе мне было трудно понять все это. Поэтому я добавил бы немного подробней в этот ответ и покажу, как я это сделал.
Поскольку @jjungnickel предположил, что для Дженкинса необходимо установить EnvInject Plugin. Затем в разделе Сборка > Добавить шаг сборки вы получите опцию "Инъекционные переменные среды".
В основном идея такова:
Здесь пример настройки:
Поскольку я хочу использовать их в maven цели, мне нужно установить флажок Inject Build Variables.
Затем в конце сборки я удаляю файл только потому, что хочу сохранить среду, как это было до сборки.