Как в Hudson установить несколько переменных среды с учетом одного параметра?

Я хочу настроить параметризованную сборку в Hudson, которая принимает только один параметр — тип создаваемой сборки (QA, Stage, Production). Однако каждая из этих сборок требует установки нескольких различных переменных среды. Что-то вроде (псевдокод):

if ${CONFIG} == "QA" then
    ${SVN_PATH} = "branches/dev"
    ${BUILD_CONFIG} = "Debug"
    # more environment variables...
else if ${CONFIG} == "Production" then
    ${SVN_PATH} = "trunk"
    ${BUILD_CONFIG} = "Release"
    # more environment variables...
else # more build configurations...
end if

Наша сборка состоит из множества шагов — получение из subversion, затем запуск комбинации команд MSBuild, пакетных файлов DOS и сценариев Powershell.

Обычно мы планируем наши сборки из интерфейса Hudson, и я хочу, чтобы запись параметра была максимально защищена от идиотов.

Есть ли способ сделать это?


environment-variables parameterized hudson
person roufamatic    schedule 03.12.2010    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Поскольку вы делаете так много вещей для релиза, как насчет того, чтобы написать все шаги за пределами Hudson? вы можете использовать ant, пакетные файлы или любой другой язык сценариев, который вы предпочитаете. Поместите этот сценарий в свой scm, чтобы получить контроль версий.

плюсы:

  • вы получаете логику от Хадсона, поскольку Хадсон только вызывает сценарий.
  • Вам не нужно создавать переменные среды, которые должны сохраняться между оболочками (глобальные переменные).
  • вы можете использовать файлы конфигурации/свойств для каждой среды, которые вы также должны поместить в систему контроля версий
  • вы можете запускать эти сценарии за пределами Hudson, если вам нужно
  • Конфигурация работы Hudson стала проще
  • у вас нет побочных эффектов изменения глобальных переменных среды. Вы всегда должны пытаться создавать задания, которые не изменяют какие-либо глобальные настройки, потому что это всегда вызывает проблемы.
person Peter Schuetze    schedule 03.12.2010
comment
Я согласен с этим подходом. Это позор, хотя одна из моих любимых вещей в Hudson — это возможность выбрать лучший инструмент для работы и использовать его. Тем не менее, чем больше я его использую, тем больше я думаю, что игнорирование всех параметров, кроме запуска сценария оболочки, является единственным действительно поддерживаемым решением. - person roufamatic; 03.12.2010
comment
Согласен, это то, что я имел в виду во втором абзаце моего ответа. +1 к списку плюсов. - person Dave Bacher; 03.12.2010

arrow_upward
2
arrow_downward

Hudson поддерживает параметры сборки, которые являются переменными времени сборки, которые Hudson делает доступными в качестве переменных среды для ваших шагов сборки (см. " rel="nofollow">параметризованная сборка на вики-странице). В вашей работе у вас может быть один параметр выбора CONFIG, который вводит пользователь. (Чтобы настроить параметр, в конфигурации задания выберите Эта сборка параметризована.)

Затем вы можете в основном написать то, что вы закодировали, в псевдокоде в начале шага сборки. Или, поскольку у вас есть несколько шагов, поместите настройку среды в файл, на который ссылаются ваши существующие сценарии сборки. (В зависимости от вашей оболочки существуют различные приемы для экспорта переменных, установленных в сценарии, в родительскую среду.) Помещение установки в файл, интегрированный с вашими существующими сценариями сборки, значительно облегчит управление и тестирование (т. е. Hudson), а также дает вам простой способ локального вызова ваших скриптов.

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

person Dave Bacher    schedule 03.12.2010
comment
Я дам вам точку, но это не очень помогает. Какие вы знаете приемы, которые позволяют мне изменить среду вызывающего процесса (java, работающий Hudson)? Я пробовал использовать SETX, а также вызывать метод .NET SetEnvironmentVariable. Оба, похоже, работают, но ни один из них не может повлиять на набор переменных среды вызывающего процесса. Таким образом, последующие вызовы моих разрозненных шагов сборки не видят изменений. То, что я действительно ищу, это что-то вроде плагина SetEnv, за исключением того, что он должен позволять немного структурированного программирования вокруг него. - person roufamatic; 03.12.2010
comment
Итак, вы говорите, что это не работает, используя setx на первом этапе сборки и получая переменные на втором этапе сборки? - person Peter Schuetze; 03.12.2010
comment
Единственное, что работает, — это использовать powershell для вызова SetEnvironmentVariable/GetEnvironmentVariable. Но это неудобно и не будет работать с другими этапами сборки (например, извлечение из subversion, сборка проектов MSBuild) (если, конечно, я не следую подходу в вашем ответе... в этом случае вся проблема меняется :-) - person roufamatic; 03.12.2010
comment
@roufamatic, мэм, нет необходимости голосовать за мой ответ, если он бесполезен. Я недостаточно знаком с пакетом и powershell, чтобы давать там полезные советы. В Linux/posix вам нужно будет создавать сценарий установки в начале каждого шага сборки, что является одной из многих причин, по которым я (и @Peter) предлагаю поместить установку в отдельный файл, чтобы избежать дублирования. - person Dave Bacher; 03.12.2010
comment
Я даю баллы людям, которые пишут четкие ответы, даже если это не совсем то, что я хочу. И теперь, когда непосредственный стресс моего дня прошел, было бы неверным сказать, что это совсем не помогло. :-) - person roufamatic; 04.12.2010