Наследование заданий в работе Дженкинса

Как вы обрабатываете сопоставление заданий Jenkins в процессе сборки и сможете ли вы построить каскадные конфигурации при наследовании?

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

Недавно я увидел QuickBuild, и у него есть наследование заданий, где родительские задания могут определять стандартную группу шагов, а его дети могут переопределять и специализироваться. С Дженкинсом у меня есть копии рабочих мест, и это нормально, пока мне не нужно что-то менять. С QuickBuild связь между заданиями позволяет мне с легкостью распространять мои изменения.

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

Как вы справляетесь с сложностью ваших заданий на строительство в Jenkins? Слышали ли вы о каких-либо серьезных проблемах с QuickBuild?

Ответ 1

Я хотел бы указать вам на выпуск плагина, который моя команда разработала и только недавно опубликовала под открытым исходным кодом. Он реализует полное "Наследование между заданиями".

Здесь для дальнейших ссылок, которые могут вам помочь:

Презентация: https://www.youtube.com/watch?v=wYi3JgyN7Xg
Wiki: https://wiki.jenkins-ci.org/display/JENKINS/inheritance-plugin
Релизы: http://repo.jenkins-ci.org/releases/hudson/plugins/project-inheritance/

Ответ 2

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

Одна из возможностей - использовать плагин . Это позволяет создать иерархию заданий. Он обеспечивает наследование для разработчиков, издателей и настроек SCM. Могу работать для некоторых, для меня этого было недостаточно.

Второе, что я проверил, это Ant Script для клонирования работы, а его брат - Bash Script. Это действительно здорово. Идея состоит в том, чтобы сделать script создание нового задания, скопировать все настройки из задания шаблона, внести изменения по мере необходимости. Поскольку это script, он очень гибкий, и вы можете много сделать с этим. Единственным недостатком является то, что это не приведет к реальной иерархии, поэтому изменения в задании шаблона не отразятся на уже клонированных работах, только на заданиях, которые будут созданы в будущем.

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

Надеюсь, что это поможет.

Ответ 3

Меня спросили, каково наше окончательное решение проблемы... После многих месяцев борьбы с нашей системой закупок мы потратили около 4000 долларов США на Quickbuild. Примерно через 2-3 месяца у нас была система шаблонов и была очень довольна. До того, как я покинул компанию, у нас было несколько групп продуктов в системе, и мы также автоматизировали процесс выпуска.

Quickbuild был отличным продуктом. Он должен быть в классе $40 тыс., Но его цена намного меньше. Хотя я уверен, что Дженкинс мог бы это сделать, это было бы немного клочья, тогда как Quickbuild использовал эту функцию. Я реализовал сложное поведение поверх продуктов раньше (например, отслеживание слияния в SVN 1.0) и сожалел об этом. Quickbuild был разумно оценен и обеспечил прочную основу для наших систем сборки и тестирования.

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

Ответ 4

Мы используем quickbuild, и, похоже, он отлично работает для большинства вещей. Я даже смог использовать их API для написания пользовательских плагинов. Одной областью, в которой отсутствует quickbuild, является интеграция сонара. У команды сонара есть плагин Jenkins, а не один для быстрой сборки.