Jenkins и многоконфигурационные (матричные) задания

Question

Почему существуют два вида работ для Дженкинса, как проект с несколькими конфигурациями, так и проект проекта в свободном стиле? Я где-то читал, что, выбрав один из них, вы не можете легко перейти на другой. Почему бы мне не всегда выбирать мультиконфигурационный проект, чтобы быть в безопасности для будущих изменений?

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

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

Итак, вкратце: как большинство людей настраивают мультиконфигурационный проект для множества разных платформ?

Answer 1

Два типа заданий имеют отдельные функции:

• Свободные задания: они позволяют вам построить свой проект на одном компьютере или ярлыке (группе компьютеров, например, «Windows-XP-32»).
• Задания с несколькими конфигурациями: они позволяют вам строить свой проект на нескольких компьютерах или ярлыках или их комбинации, например, для Windows-XP, Windows-Vista, Windows-7 и RedHat - , полезных для проверки совместимость или сборка для нескольких платформ (программы qt?)

Если у вас есть проект, который вы хотите построить на Windows & Unix, у вас есть два варианта:

• Создайте отдельное задание в свободном стиле для каждой конфигурации, и в этом случае вам нужно поддерживать каждое из них отдельно
• У вас есть одно мультиконфигурационное задание, и вы выбираете 2 (или более) меток / компьютеров / ведомых - 1 для Windows и 1 для Unix. В этом случае вам нужно сохранить только одно задание для сборки

Вы можете хранить версии gcc на одной оси, а версии программного обеспечения - на другой. Нет причин, по которым ты не сможешь.

Вопрос, который вы связываете, имеет справедливую точку зрения, но тот, который не имеет отношения к вашему вопросу напрямую: в его случае он выполнял задание с несколькими конфигурациями A , которое - в случае успеха - вызвало другое работа B . Теперь, в задании с несколькими конфигурациями, если одна из конфигураций дает сбой, происходит сбой всего задания (очевидно, поскольку вы хотите, чтобы ваш проект был успешно построен на всех ваших конфигурациях).

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

Answer 2

Другой вариант - использовать шаг сборки python для проверки текущей ОС, а затем вызвать соответствующий скрипт установки или сборки. В скрипте python вы можете сохранить обновленную среду в файл и снова внедрить среду, используя плагин EnvInject для последующих этапов сборки. В зависимости от размера вашей среды сборки вы также можете использовать многоплатформенный инструмент сборки, такой как SCons.

Answer 3

Можно использовать пользовательскую ось в сочетании с ведомыми (windows, linux, ...), поэтому вам нужно добавить фильтр для каждой комбинации и использовать плагин Conditional BuildStep, чтобы задать шаг сборки, специфичный для каждой из платформ.(Executar shell, команда Windows, ...)

Эта ссылка имеет учебное пособие, но оно на португальском языке, но ее легко разобрать на основе изображения ... http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas-configuracoes-matrix-no-jenkins/

Answer 4

Вы можете создать скрипт (например, build ) и командный файл (например, build.bat ), который будет проверен с вашим исходным кодом.В Jenkins на вашем этапе сборки вы можете вызвать $ WORKSPACE / build - Windows выполнит build.bat , тогда как Linux будет запускать build .

Answer 5

Если вы пойдете по матричному пути с Windows и чем-то еще, вам понадобится плагин XShell.Вы просто создаете два сценария сборки, такие как «build.bat» для cmd и «build» для bash, и говорите XShell запустить «build».Правильный будет запущен в каждом случае.

Answer 6

Вы можете использовать переменную, которую Дженкинс создает при определении оси матрицы конфигурации. Например: Вы создаете подчиненную ось с именем OSTYPE и проверяете двух ведомых (Windows и Linux). Затем вы создаете два отдельных шага сборки и проверяете переменную среды OSTYPE.

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

Answer 7

Почему бы вам не выбрать тип работы с несколькими конфигурациями?

На ум приходят некоторые причины:

1. Поскольку задания должны легко создаваться и настраиваться. Если вам сложно настроить какую-либо работу в вашей среде, вы, вероятно, делаете что-то не так, выходя за рамки работы Дженкинса. Если вы счастливы, что вам удалось создать эту единственную работу, и она наконец-то запустилась, и вы не хотите делать всю эту работу снова, вот где вы должны попытаться улучшить.
2. Поскольку многоконфигурационные задания более сложны. Как правило, они требуют, чтобы вы думали как о основной работе, так и о различных переменных подзадачи, и они имеют тенденцию возрастать в сложности до уровня, который невозможно контролировать. Таким образом, в одном сценарии работы вы, вероятно, будете тратить мысли о том, чтобы не использовать эту сложность, и при расширении переменных сборки все может развиваться в неправильном направлении. Я бы предложил использовать простые задания по умолчанию и задания с несколькими конфигурациями, только если требуется несколько конфигураций.
3. Поскольку для выполнения нескольких заданий конфигурации может потребоваться больше слотов заданий на ведомых устройствах, чем на отдельных заданиях. Всегда будет главное задание, которое выполняется в специальном невидимом слоте (само по себе это не проблема) и запускает подзадачи, но если эти подзадачи сами запускают подзадачи, вы можете легко зайти в тупик, если есть больше подзадач, чем слотов, и некоторые подзадачи снова запускают подзадачи, которые затем не могут быть выполнены, так как больше нет открытых слотов. Эту проблему можно обойти, используя некоторые настройки конфигурации на ведомых устройствах, но она присутствует и может возникнуть, только если несколько одновременных заданий выполняются одновременно.

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

Answer 8

Взломать запуск пакетных файлов в Windows и сценарии оболочки в Unix:

В Unix заставить пакетные файлы завершиться с 0 состоянием выхода:

ln -s /bin/true /bin/cmd

В Windows либо найдите true.exe, назовите его sh.exe и поместите его где-нибудь в PATH.

В качестве альтернативы, если у вас установлен sh.exe в Windows (из Cygwin, Git или другогоисточник), добавьте это в начало сценария оболочки в Jenkins:

[ -n "$WINDIR" ] && exit 0

Answer 9

Если вы хотите выбрать, на каком ведомом устройстве вы запускаете задание, вам нужно использовать проект с несколькими конфигурациями (иначе вы не сможете выбрать / ограничить ведомые устройства, на которых вы его выполняете - есть три способа сделать это. Тем не менее, я попробовал их все (плагин Tie работает только для основной работы, Restrict в Advanced Project Options также не является безопасным триггером, поэтому вы хотите использовать подчиненную ось, которая, как доказано, работает сегодня.)