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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

ln -s /bin/true /bin/cmd

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

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

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

Ответ 8

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

Приходят в голову некоторые причины:

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

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

Ответ 9

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