Подтвердить что ты не робот

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

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

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

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

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

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


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

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

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

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

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

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

Ответ 1

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

nosetests --with-xunit --enable-cover

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

Аналогичным образом вы можете записать вывод pylint с помощью плагина для Jenkins.

Ответ 2

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

Ответ 3

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

Если, конечно, поддерживает такие функции, как запуск на нескольких компьютерах, и это намного проще в настройке и обслуживании, чем buildbot.

Ответ 5

Я предполагаю, что эта ветка довольно старая, но вот мой подход к ней с помощью hudson:

Я решил пойти с пипсом и настроить репо (болезненное, чтобы получить работу, но приятно выглядящий eggbasket), который hudson автоматически загружает с успешными испытаниями. Вот мой грубый и готовый script для использования с hudson config execute script вроде:/var/lib/hudson/venv/main/bin/hudson_script.py -w $WORKSPACE -p my.package -v $BUILD_NUMBER, просто введите **/coverage.xml, pylint.txt и nosetests.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 и зависимостями, которые вы можете просто проверить в багажнике и запустить на нем этот материал.

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

------ обновление ---------

Я добавил epydoc, который прекрасно вписывается в hudson. Просто добавьте javadoc в свою конфигурацию с помощью html-папки

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

Ответ 6

Atlassian Bamboo также определенно стоит проверить. Вся атласская сюита (JIRA, Confluence, FishEye и т.д.) Довольно мила.

Ответ 7

еще один: Shining Panda является размещенным инструментом для python

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

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