“Симпатичная” непрерывная интеграция для Python
-
03-07-2019 - |
Вопрос
Это немного..напрасный вопрос, но вывод 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
Другие советы
Мы добились большого успеха с 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-парня или инженера/архитектора Принципиального уровня, действительно зайдет так далеко.Это просто хорошая идея и потенциальный опыт обучения, поскольку сервер сборки — это не что иное, как способ произвольного выполнения сценариев в автоматическом режиме.