Jenkins и многоконфигурационные (матричные) задания
Почему у Дженкинса есть два вида работ: проект с несколькими конфигурациями и проект в свободном стиле? Я где-то читал, что, выбрав один из них, вы не можете легко перейти на другой. Почему бы мне не всегда выбирать мультиконфигурационный проект, чтобы быть в безопасности для будущих изменений?
Я хотел бы настроить сборку для сборки проекта как на Windows, так и на Unix (и на других платформах). Я нашел этот вопрос), который задает то же самое, но я действительно не получаю ответ. Зачем мне нужно три матричных проекта (а не три проекта в свободном стиле), по одному для каждой платформы? Почему я не могу хранить их все в одной матрице с платформами И (например) версией gcc на одной оси и (моими) версиями программного обеспечения на другой?
Я также читал этот пост в блоге, но он собирает все на одной машине с разными версиями Python.
Итак, вкратце: как большинство людей настраивают мультиконфигурационный проект, ориентированный на множество разных платформ?
9 ответов
Два типа заданий имеют отдельные функции:
- Задания в свободном стиле: они позволяют вам создать свой проект на одном компьютере или ярлыке (группа компьютеров, например, "Windows-XP-32").
- Задания с несколькими конфигурациями: они позволяют вам строить свой проект на нескольких компьютерах или ярлыках или их комбинации, например, для Windows-XP, Windows-Vista, Windows-7 и RedHat - полезно для проверки совместимости или сборки для нескольких платформ. (QT программы?)
Если у вас есть проект, который вы хотите построить на Windows & Unix, у вас есть два варианта:
- Создайте отдельное задание в свободном стиле для каждой конфигурации, и в этом случае вам нужно поддерживать каждую из них отдельно
- У вас есть одно мультиконфигурационное задание, и вы выбираете 2 (или более) меток / компьютеров / ведомых - 1 для Windows и 1 для Unix. В этом случае вам нужно сохранить только одну работу для сборки.
Вы можете хранить свои версии gcc на одной оси, а версии программного обеспечения - на другой. Нет причин, по которым ты не сможешь.
Вопрос, который вы связываете, имеет справедливое значение, но тот, который непосредственно не связан с вашим вопросом: в его случае у него было многоконфигурационное задание A, которое - в случае успеха - вызвало другое задание B. Теперь в задании с несколькими конфигурациями, если происходит сбой одной из конфигураций, происходит сбой всего задания (очевидно, так как вы хотите, чтобы ваш проект был успешно построен на всех ваших конфигурациях).
ИМХО, для построения одного и того же проекта на нескольких платформах лучше всего использовать работу в стиле нескольких конфигураций.
Другой вариант - использовать шаг сборки Python для проверки текущей ОС, а затем вызвать соответствующий скрипт установки или сборки. В скрипте python вы можете сохранить обновленную среду в файл и снова внедрить среду, используя плагин EnvInject для последующих этапов сборки. В зависимости от размера вашей среды сборки вы также можете использовать многоплатформенный инструмент сборки, такой как SCons.
Вы можете создать скрипт (например, build) и командный файл (например, build.bat), который будет проверен с вашим исходным кодом. В Jenkins на вашем этапе сборки вы можете вызвать $ WORKSPACE / build - Windows выполнит build.bat, тогда как Linux запустит build.
Один из вариантов - использовать пользовательскую ось в сочетании с ведомыми (windows, linux, ...), поэтому вам нужно добавить фильтр для каждой комбинации и использовать плагин Conditional BuildStep, чтобы задать шаг сборки, специфичный для каждой платформы (оболочка Executar)., Команда Windows,...)
У этой ссылки есть учебное пособие, но оно на португальском языке, но его легко решить, основываясь на изображении... http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas-configuracoes-matrix-no-jenkins/
Если вы пойдете по матричному пути с Windows и чем-то еще, вам понадобится плагин XShell. Вы просто создаете два сценария сборки, такие как "build.bat" для cmd и "build" для bash, и говорите XShell запустить "build". Правильный будет запущен в каждом случае.
Вы можете использовать переменную, которую Дженкинс создает при определении оси матрицы конфигурации. Например: вы создаете подчиненную ось с именем OSTYPE и проверяете двух подчиненных (Windows и Linux). Затем вы создаете два отдельных шага сборки и проверяете переменную среды OSTYPE.
Вместо этого вы можете использовать улучшенный язык сценариев, такой как python, который является мультиплатформенным и может достичь той же функциональности независимо от имени ведомых и всего за один шаг сборки.
Взлом для запуска командных файлов в Windows и сценариев оболочки в Unix:
В Unix заставить пакетные файлы выходить с 0 статусом выхода:
ln -s /bin/true /bin/cmd
На винде либо найди true.exe, назови это sh.exe и поместите это где-нибудь в ПУТИ.
В качестве альтернативы, если у вас есть sh.exe установленный в Windows (из Cygwin, Git или другого источника), добавьте это в начало сценария оболочки в Jenkins:
[ -n "$WINDIR" ] && exit 0
Почему бы вам не выбрать тип работы с несколькими конфигурациями?
На ум приходят несколько причин:
- Потому что рабочие места должны быть легко создавать и настраивать. Если вам сложно настроить какую-либо работу в вашей среде, вы, вероятно, делаете что-то не так, выходя за рамки работы Дженкинса. Если вы счастливы, что вам удалось создать эту единственную работу, и она, наконец, запустилась, и вы неохотно делаете всю эту работу снова, вот где вы должны попытаться улучшить.
- Потому что многоконфигурационные задания более сложны. Как правило, они требуют, чтобы вы думали как о основной работе, так и о различных переменных подзадачи, и они имеют тенденцию возрастать в сложности до уровня, не поддающегося управлению. Таким образом, в одном сценарии работы вы, вероятно, будете тратить мысли о том, чтобы не использовать эту сложность, и при расширении переменных сборки все может развиваться в неправильном направлении. Я бы порекомендовал использовать простые задания по умолчанию и задания с несколькими конфигурациями, только если есть необходимость в нескольких конфигурациях.
- Потому что для выполнения нескольких заданий конфигурации может потребоваться больше слотов заданий на ведомых устройствах, чем на отдельных заданиях. Всегда будет главное задание, которое выполняется в специальном невидимом слоте (само по себе это не проблема) и запускает подзадачи, но если эти подзадачи сами запускают подзадачи, вы можете легко зайти в тупик, если есть больше подзадач, чем слотов, и некоторые подзадачи снова запускают подзадачи, которые затем не могут быть выполнены, так как больше нет открытых слотов. Эту проблему можно обойти, используя некоторые настройки конфигурации на ведомых устройствах, но она присутствует и может возникнуть, только если несколько одновременных заданий выполняются одновременно.
Итак, по сути: работа с несколькими конфигурациями - это более сложная вещь, и поскольку ее следует избегать, если в этом нет необходимости, обычная работа по фристайлу лучше по умолчанию.
Если вы хотите выбрать, на каком ведомом устройстве вы запускаете задание, вам нужно использовать проект с несколькими конфигурациями (иначе вы не сможете выбрать / ограничить ведомые устройства, на которых вы его выполняете - есть три способа сделать это, однако я Опробовал их все (плагин Tie работает только для основной работы, Restrict в Advanced Project Options также не является безопасным триггером, поэтому вы хотите использовать ведомую ось, которая, как доказано, работает сегодня.)