“Симпатичная” непрерывная интеграция для Python

StackOverflow https://stackoverflow.com/questions/225598

Вопрос

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

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

.. и другие, Строительный бот выглядит довольно..архаичный

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

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

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

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

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

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

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

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

Решение

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

nosetests --with-xunit --enable-cover

Это будет полезно, если вы хотите пойти по пути Дженкинса или использовать другой CI-сервер, поддерживающий отчеты о тестах JUnit.

Аналогичным образом вы можете получить вывод pylint, используя команду Плагин нарушений для Jenkins

Другие советы

Не знаю, подойдет ли: Укушенный создан ребятами, которые пишут Trac, и интегрирован с Trac. Апач Гамп — это инструмент CI, используемый Apache.Он написан на Python.

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

Если, конечно, поддерживает такие вещи, как запуск на нескольких машинах, и его гораздо проще настроить и поддерживать, чем buildbot.

Страницу-водопад Buildbot можно значительно улучшить.Вот хороший пример http://build.chromium.org/buildbot/waterfall/waterfall

Атласиан Бамбук тоже определенно стоит посмотреть.Весь пакет Atlassian (JIRA, Confluence, FishEye и т. д.) довольно хорош.

Я думаю, что эта тема довольно старая, но вот мое мнение о Хадсоне:

Я решил использовать pip и создал репо (трудно работать, но красиво выглядящая корзина для яиц), в которую Hudson автоматически загружает результаты успешных тестов.Вот мой примерный и готовый сценарий для использования со сценарием выполнения конфигурации Hudson, например:/var/lib/hudson/venv/main/bin/hudson_script.py -w $WORKSPACE -p my.package -v $BUILD_NUMBER, просто вставьте **/coverage.xml, pylint.txt и носетестс.xml в конфигурацию биты:

#!/var/lib/hudson/venv/main/bin/python
import os
import re
import subprocess
import logging
import optparse

logging.basicConfig(level=logging.INFO,
                    format='%(asctime)s %(levelname)s %(message)s')

#venvDir = "/var/lib/hudson/venv/main/bin/"

UPLOAD_REPO = "http://ldndev01:3442"

def call_command(command, cwd, ignore_error_code=False):
    try:
        logging.info("Running: %s" % command)
        status = subprocess.call(command, cwd=cwd, shell=True)
        if not ignore_error_code and status != 0:
            raise Exception("Last command failed")

        return status

    except:
        logging.exception("Could not run command %s" % command)
        raise

def main():
    usage = "usage: %prog [options]"
    parser = optparse.OptionParser(usage)
    parser.add_option("-w", "--workspace", dest="workspace",
                      help="workspace folder for the job")
    parser.add_option("-p", "--package", dest="package",
                      help="the package name i.e., back_office.reconciler")
    parser.add_option("-v", "--build_number", dest="build_number",
                      help="the build number, which will get put at the end of the package version")
    options, args = parser.parse_args()

    if not options.workspace or not options.package:
        raise Exception("Need both args, do --help for info")

    venvDir = options.package + "_venv/"

    #find out if venv is there
    if not os.path.exists(venvDir):
        #make it
        call_command("virtualenv %s --no-site-packages" % venvDir,
                     options.workspace)

    #install the venv/make sure its there plus install the local package
    call_command("%sbin/pip install -e ./ --extra-index %s" % (venvDir, UPLOAD_REPO),
                 options.workspace)

    #make sure pylint, nose and coverage are installed
    call_command("%sbin/pip install nose pylint coverage epydoc" % venvDir,
                 options.workspace)

    #make sure we have an __init__.py
    #this shouldn't be needed if the packages are set up correctly
    #modules = options.package.split(".")
    #if len(modules) > 1: 
    #    call_command("touch '%s/__init__.py'" % modules[0], 
    #                 options.workspace)
    #do the nosetests
    test_status = call_command("%sbin/nosetests %s --with-xunit --with-coverage --cover-package %s --cover-erase" % (venvDir,
                                                                                     options.package.replace(".", "/"),
                                                                                     options.package),
                 options.workspace, True)
    #produce coverage report -i for ignore weird missing file errors
    call_command("%sbin/coverage xml -i" % venvDir,
                 options.workspace)
    #move it so that the code coverage plugin can find it
    call_command("mv coverage.xml %s" % (options.package.replace(".", "/")),
                 options.workspace)
    #run pylint
    call_command("%sbin/pylint --rcfile ~/pylint.rc -f parseable %s > pylint.txt" % (venvDir, 
                                                                                     options.package),
                 options.workspace, True)

    #remove old dists so we only have the newest at the end
    call_command("rm -rfv %s" % (options.workspace + "/dist"),
                 options.workspace)

    #if the build passes upload the result to the egg_basket
    if test_status == 0:
        logging.info("Success - uploading egg")
        upload_bit = "upload -r %s/upload" % UPLOAD_REPO
    else:
        logging.info("Failure - not uploading egg")
        upload_bit = ""

    #create egg
    call_command("%sbin/python setup.py egg_info --tag-build=.0.%s --tag-svn-revision --tag-date sdist %s" % (venvDir,
                                                                                                              options.build_number,
                                                                                                              upload_bit),
                 options.workspace)

    call_command("%sbin/epydoc --html --graph all %s" % (venvDir, options.package),
                 options.workspace)

    logging.info("Complete")

if __name__ == "__main__":
    main()

Когда дело доходит до развертывания, вы можете сделать что-то вроде:

pip -E /location/of/my/venv/ install my_package==X.Y.Z --extra-index http://my_repo

И тогда люди смогут разрабатывать вещи, используя:

pip -E /location/of/my/venv/ install -e ./ --extra-index http://my_repo

Предполагается, что у вас есть структура репо для каждого пакета с setup.py и всеми настроенными зависимостями, после чего вы можете просто проверить магистраль и запустить на ней все это.

Надеюсь, это кому-то поможет.

------обновлять---------

Я добавил эпидок, который очень хорошо сочетается с Хадсоном.Просто добавьте javadoc в свою конфигурацию с папкой html.

Обратите внимание, что в настоящее время pip не поддерживает флаг -E должным образом, поэтому вам придется создать свой venv отдельно.

Еще один : Сияющая Панда это размещенный инструмент для Python

Если вы рассматриваете размещенное решение CI и используете открытый исходный код, вам следует изучить Трэвис КИ кроме того, у него очень хорошая интеграция с GitHub.Хотя это начиналось как инструмент Ruby, у них есть добавлена поддержка Python некоторое время назад.

Сигнал — еще один вариант.Вы можете узнать больше об этом, а также посмотреть видео здесь.

я бы рассмотрел КругCi - у него отличная поддержка Python и очень красивый результат.

континуум бинстар теперь может запускать сборки из github и компилировать для Linux, OSX и Windows (32/64).Самое приятное то, что он действительно позволяет тесно связать распространение и непрерывную интеграцию.Это значит пересечь все границы и расставить точки над «И» в интеграции.Сайт, рабочий процесс и инструменты действительно отточены, и AFAIK conda — это самый надежный и питонический способ распространения сложных модулей Python, где вам нужно обернуть и распространять библиотеки C/C++/Fotran.

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top