«Довольно» непрерывной интеграции для Python

Question

Это немного .. напрасный вопрос, но вывод BuildBot не особенно хорош для рассмотрения ..

Например, по сравнению с ..

• phpUnderControl
• Дженкинс
  • Hudson
• CruiseControl.rb

.. и другие BuildBot выглядит довольно .. архаично

В настоящее время я играю с Хадсоном, но он очень ориентирован на Java (хотя с этим руководством я нашел его проще в настройке, чем BuildBot, и получил больше информации)

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

---

Обновление: С этого времени проект Jenkins заменил Hudson как версию пакета для сообщества. Авторы оригинала также перешли к этому проекту. Теперь Jenkins является стандартным пакетом для Ubuntu / Debian, RedHat / Fedora / CentOS и других. Следующее обновление все еще по существу правильно. Начальная точка для этого с Jenkins отличается.

Обновление: Попробовав несколько альтернатив, я думаю, что останусь с Хадсоном. Целостность была приятной и простой, но довольно ограниченной. Я думаю, что Buildbot лучше подходит для использования множества сборочных ведомых, а не для того, чтобы все работало на одной машине, как я ее использовал.

Настройка Hudson для проекта Python была довольно простой:

• Скачать Hudson с http://hudson -ci.org /
• Запустите его с java -jar hudson.war
• Открыть веб-интерфейс по адресу по умолчанию http://localhost:8080
• Зайдите в Управление Hudson, Плагины, нажмите «Обновить» или подобное
• Установите плагин Git (мне пришлось установить путь git в глобальных настройках Hudson)
• Создайте новый проект, введите репозиторий, интервалы опроса SCM и т. Д.
• Установите nosetests через easy_install, если это еще не
• На этапе сборки добавьте nosetests --with-xunit --verbose
• Установите флажок «Опубликовать отчет о результатах тестирования JUnit» и установите для «XML отчета о тестировании» значение **/nosetests.xml

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

• Плагин SLOCCount для подсчета строк кода (и построения графика!) - вам нужно установить sloccount отдельно
• Нарушения для анализа вывода PyLint (вы можете настроить пороги предупреждений, график количества нарушений для каждой сборки)
• Cobertura может анализировать файл cover.py. Nosetest может собрать покрытие во время выполнения ваших тестов, используя nosetests --with-coverage (это записывает вывод в **/coverage.xml)

Answer 1

континуум binstar теперь может запускать сборки из github и может компилироваться для linux, osx и windows (32/64). Важно то, что он действительно позволяет вам тесно связать распределение и непрерывную интеграцию. Это пересечение T и расставление точек I интеграции. Сайт, рабочий процесс и инструменты действительно отточены, и AFAIK conda является наиболее надежным и питонным способом распространения сложных модулей python, где вам нужно обернуть и распространять библиотеки C / C ++ / Fotran.

Answer 2

Небольшой отказ от ответственности, на самом деле мне пришлось создать подобное решение для клиента, которому нужен был способ автоматического тестирования и развертывания любого кода в git push, а также для управления заявками на проблемы с помощью git notes. Это также привело к моей работе над проектом AIMS .

Можно легко настроить систему «голых» узлов, в которой есть пользователь сборки, и управлять их сборкой через make(1), expect(1), crontab(1) / systemd.unit(5) и incrontab(1). Можно даже пойти еще дальше и использовать ansible и celery для распределенных сборок с хранилищем файлов gridfs / nfs.

Хотя я бы не ожидал, что кто-либо, кроме парня из Graybeard UNIX или инженера / архитектора уровня Принципа, действительно зайдет так далеко. Это просто хорошая идея и потенциальный опыт обучения, поскольку сервер сборки - это не что иное, как способ произвольного выполнения скриптовых задач в автоматическом режиме.

Answer 3

Проверка rultor.com . Как объясняет эта статья , он использует Docker для каждой сборки. Благодаря этому вы можете настроить все, что вам нравится внутри вашего образа Docker, включая Python.

Answer 4

Мы привыкли кусать совсем немного. Он симпатичен и хорошо интегрируется с Trac, но его сложно настроить, если у вас есть нестандартный рабочий процесс. Также не так много плагинов, как для более популярных инструментов. В настоящее время мы оцениваем Hudson как замену.