«Досить» безперервна інтеграція для Python

Це трохи .. марне питання, але висновок BuildBot не особливо приємно дивитись ..

Наприклад, порівняно з ..

• phpUnderControl
• Дженкінс
  • Гудсон
• CruiseControl.rb

..і інші, BuildBot виглядає досить .. архаїчно

Зараз я граю з Хадсоном, але він дуже орієнтований на Java (хоча за допомогою цього посібника мені було легше налаштувати, ніж BuildBot, і я отримав більше інформації)

В основному: чи існують системи безперервної інтеграції, спрямовані на python, які дають безліч блискучих графіків і подібних?

Оновлення: з цього часу проект Дженкінса замінив Хадсона як спільну версію пакету. Оригінальні автори також перейшли до цього проекту. Зараз Дженкінс є стандартним пакетом для Ubuntu / Debian, RedHat / Fedora / CentOS та інших. Наступне оновлення все ще по суті правильне. Вихідний пункт для цього з Дженкінсом інший.

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

Налаштування Хадсона для проекту Python було досить просто:

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

Це все, що потрібно. Ви можете налаштувати сповіщення електронною поштою, і плагіни варто переглянути. Кілька я зараз використовую для проектів Python:

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

Ви можете перевірити Ніс і вихідний плагін Xunit . Ви можете запустити тести блоку та перевірку покриття за допомогою цієї команди:

nosetests --with-xunit --enable-cover

Це буде корисно, якщо ви хочете пройти маршрут Дженкінса або якщо ви хочете використовувати інший сервер CI, який підтримує звітність про тест JUnit.

Аналогічно ви можете зафіксувати вихід pylint, використовуючи плагін порушення для Jenkins

Не знаю, чи вдасться це: Bitten зроблений хлопцями, які пишуть Trac і інтегрований з Trac. Apache Gump - це інструмент CI, який використовується Apache. Це написано Python.

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

Якщо, звичайно, підтримує такі речі, як запуск на декількох машинах, і налаштувати та підтримувати його набагато простіше, ніж для роботи.

Сторінка водоспаду Buildbot може бути значно попередньо уточнена. Ось приємний приклад http://build.chromium.org/buildbot/waterfall/waterfall

Бамбук Atlassian, безумовно, варто перевірити. Весь набір атласів (JIRA, Confluence, FishEye тощо) досить милий.

Я думаю, цей потік досить старий, але ось мій погляд на нього з Гудзоном:

Я вирішив поїхати з pip та встановив репо (болісно працювати, але приємно виглядає яєчний кошик), який Гудсон автоматично завантажує з успішними тестами. Ось мій грубий і готовий сценарій для використання із сценарієм виконання файлів hudson, як-от: /var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER, просто введіть ** / покриття.xml, pylint.txt та nostests.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, який дуже добре вписується в хідсон. Просто додайте в конфігурацію javadoc за допомогою папки html

Зауважте, що піп не підтримує прапор -E належним чином, тому вам доведеться створювати свій вентилятор окремо

ще один: Shining Panda - це розміщений інструмент для python

Якщо ви розглядаєте прийняте рішення CI та працюєте з відкритим кодом, вам слід також заглянути в Travis CI - він має дуже гарну інтеграцію з GitHub. Поки він починався як інструмент Ruby, вони ще деякий час додали підтримку Python .

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

Я б вважав, що CircleCi - він має чудову підтримку Python та дуже гарний вихід.

Бінстар континууму тепер може запускати збірки з github і може компілювати для Linux, OSX та Windows ( 32/64 ). акуратним є те, що це дійсно дозволяє тісно з'єднати розподіл і постійну інтеграцію. Це схрещування т-х і крапка I інтеграції. Сайт, робочий процес та інструменти справді відполіровані, а AFAIK conda - найміцніший та пітонічний спосіб розповсюдження складних модулів python, де потрібно обернути та розповсюдити бібліотеки C / C ++ / Fotran.

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

Перевірте rultor.com . Як пояснюється в цій статті , він використовує Docker для кожної збірки. Завдяки цьому ви можете налаштувати все, що завгодно, у вашому зображенні Docker, включаючи Python.

Невелика відмова від відповідальності, я фактично повинен був створити таке рішення для клієнта, який хотів спосіб автоматично перевірити і розгорнути будь-який код на git push, а також керувати видачею квитків за допомогою git notes. Це також призвело до моєї роботи над проектом AIMS .

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

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