Какой сервер непрерывной интеграции может ставить задания в очередь?

Вариант использования:

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

Какой CI-сервер может справиться с этим?

Моим дополнительным, менее важным требованием является то, что я использую Python и желательно использовать программное обеспечение, написанное на Python, поэтому я посмотрел проект Buildbot, и особенно хочу увидеть отзывы об этом инструменте в плане его использования в целом и способен ли он заменить самые популярные решения, такие как Travis или Jenkins.


person Gill Bates    schedule 19.05.2014    source источник


Ответы (5)


Я использовал jenkins для этого. (в основном с подрывной деятельностью, сборкой c/c++, а также заданиями по сценарию bash/python)

Самая простая и стандартная обработка изменений VCS/SCM в jenkins — опрос изменений в установленное время. Сборка запускается, если есть какие-либо изменения. При использовании этого метода в сборку может быть включено более одного коммита (например, если 2 коммита выполняются близко друг к другу). Jenkins показывает ссылки на выполненное обновление scm и scm, а также показывает журналы сборки, и вы можете легко настроить выходные данные сборки и представление результатов тестирования.

https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-Buildsbysourcechanges

Какой VCS/SCM вы используете? Jenkins взаимодействует с несколькими VCS/SCM: https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Sourcecodemanagement

Этот вопрос отвечает на вопрос, как сделать сборку Jenkins для каждой фиксации subversion: Jenkins CI: как запускать сборки при фиксации SVN

person gaoithe    schedule 22.05.2014
comment
Что вы подразумеваете под тем, что в сборку может быть включено более одного коммита? - person Gill Bates; 22.05.2014
comment
Если два коммита расположены близко друг к другу, они могут быть совмещены в одной сборке. Я упомянул самый простой метод, так как это операция по умолчанию, которую действительно очень легко заставить работать. Ответ на «Jenkins CI: как запускать сборки при фиксации SVN» объясняет самый простой метод и как использовать хук subversion для запуска сборки при каждой фиксации. - person gaoithe; 22.05.2014
comment
Я считаю это плохой вещью, потому что, если тесты провалились, вы не можете сказать, какой коммит их ломает. - person Gill Bates; 22.05.2014
comment
В ответе два варианта: 1. самый простой, но с этой проблемой 2. использование хука svn, описанного в другом вопросе и в документах плагина jenkins subversion. - person gaoithe; 22.05.2014
comment
В Jenkins нет возможности помещать задачи в очередь? - person Gill Bates; 22.05.2014
comment
Вакансии, естественно, имеют очередь в jenkins. Либо с опросом, либо с решениями для перехвата заданий запускаются одно за другим (они используют одно и то же рабочее пространство для проверки/сборки/тестирования). - person gaoithe; 22.05.2014

TeamCity бесплатна (до нескольких сборок и агентов сборки) и многофункциональна. Его очень легко установить и настроить, хотя может потребоваться некоторое время, чтобы разобраться в богатстве опций. Он очень хорошо задокументирован: http://www.jetbrains.com/teamcity/documentation/

Он написан на Java, но поддерживает многие инструменты изначально, а другие — через выполнение из командной строки, поэтому вы можете создавать с его помощью все, что захотите. (Я использую его в основном для Ruby.) Он понимает вывод многих инструментов тестирования; если вы не используете один из них, возможно, ваш может эмулировать их вывод. Его можно расширить; у него есть REST API и плагин API.

Его можно настроить для сборки каждой фиксации, или для сборки всех коммитов, поступивших за определенный период времени, или для запуска другими способами. Документы здесь: http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers

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

person Dave Schweisguth    schedule 24.05.2014

Я не хочу, чтобы CI-сервер запускал задания параллельно, чтобы избежать проблем с производительностью и сбоев в случае множества одновременных заданий.

В buildbot вы можете ограничить количество запущенных заданий в подчинении с помощью max_build или блокировки

person hithwen    schedule 22.05.2014
comment
Связанный вопрос: избегайте одновременного запуска сборщиков в buildbot - person hithwen; 29.05.2014

Что касается Buildbot и Python, вы можете координировать параллельные сборки по конфигурации, например:

Моделирование параллельных процессов: шаги

svn up
configure
make
make test
make dist

Кроме того, вы также можете попробовать использовать триггерный планировщик для вашего компоновщика, который выполняет шаги U, V, W.

Из документов:

Планировщик Triggerable ожидает запуска на шаге Trigger (см. Запуск планировщиков) в другой сборке. Этот шаг может дополнительно дождаться завершения сборки планировщика. Это дает два преимущества по сравнению с зависимыми планировщиками.

Ссылки:

person Yair Nevet    schedule 22.05.2014
comment
Насколько я понимаю, организация очередей является функцией Buildbot по умолчанию, как указано на его веб-странице: В основе своей , Buildbot — это система планирования заданий: она ставит задания в очередь. Это вообще хороший инструмент, можете ли вы рассказать больше о своем опыте работы с ним? Я гуглил об интеграции Buildbot с Pytest или PyUnit (модуль unittest в стандартной библиотеке Python), но ничего не нашел, как в Buildbot осуществляется интеграция с тестовыми фреймворками? Могу ли я сохранять результаты для сборок? - person Gill Bates; 29.05.2014

Существует плагин Throttle Concurrent Builds Plugin для Jenkins и Hudson. Это позволяет указать количество одновременных сборок для каждого задания. Вот что написано на странице плагина:

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

Существует также Gitlab CI, очень хороший современный проект Ruby, который использует бегунов для распространения сборок, так что вы могли бы, я думаю, ограничить количество бегунов до 1, чтобы получить нужный вам эффект. Он тесно интегрирован с Gitlab, поэтому я не знаю, насколько сложно будет использовать его как отдельный сервис.

www.gitlab.com

www.gitlab.com/gitlab-ci

Чтобы запускать тесты только один раз для каждой ревизии, вы можете сделать что-то вроде этого:

  1. строить
  2. post-build
    • check if the revision of the build is in /tmp/jenkins-test-run
    • если ревизия есть в файле пропустить тесты
    • если ревизия НЕ в файле запускает тесты
    • если мы запускали тесты то пишем ID в /tmp/jenkins-test-run
person Tomislav Skunca    schedule 29.05.2014