Travis yml что это
Что такое travis-ci.org и с чем его едят?
Наверняка все слышали шумиху вокруг проекта travis-ci.org. Я не являюсь исключением и учитывая, что один из его разработчиков, Джош Калдеримис (Josh Kalderimis), выступивший на прошедшей конференции toster.ru, разжег мой интерес еще больше, то я решил окончательно разобраться, что такое travis-ci и с чем его едят. После прочтения вы узнаете как данный сервис может помочь ruby-разработчикам, а также как ему могут помочь они. Располагайтесь поудобнее, начнем.
Непрерывная интеграция
Как оказалось, термин «continuous integration» достаточно старый. Он был введен Мартином Фаулером (Martin Fowler) в 2000-ом году и изложен в статье «Continuous Integration» и по-русски звучит как «непрерывная интеграция». Это часть процесса разработки, в которой разрабатываемый проект собирается/тестируется в различных средах выполнения автоматически и непрерывно. Задумывалась данная методика для наиболее быстрого выявления ошибок/противоречий интеграции проекта, а соотвественно снижения расходов на последующие простои.
Принцип достаточно прост: на отдельной машине работает некая служба, в обязанности которой входит получение исходного кода проекта, его сборка, тестирование, логирование, а также возможность предоставить для анализа данные выполнения перечисленных операций.
Конечно же, бесплатный сыр бывает только в мышеловке и за удобство необходимо платить: выделить отдельный сервер и поддерживать его в рабочем состоянии, обеспечить наличие необходимых программных комплексов, настроить среды выполнения, делать резервные копии данных и т.д. Все это требует немало времени и ресурсов. И вполне логичным кажется возможность делегировать эту ответсвенность на сторонние сервисы. Вот как раз таким и является travis-ci — «хостинг непрерывной интеграции для open source сообщества». Пришло время посмотреть на него поближе.
Техническая сторона
Travis-ci поддерживает множество языков программирования среди которых есть и ruby (что неудивительно, т.к. изначально он разрабатывался для ruby-проектов). Начать пользоваться сервисом очень просто. Нужно всего лишь предпринять несколько шагов, которые подробно описаны в собственном гайде проекта. Я лишь опишу процесс в целом.
Подключаемся
Если настройка прошла успешно, то travis-ci начинает непрерывно тестировать проект, отображая при этом текущий статус: красный цвет (возникли проблемы при тестировании), желтый (есть предупреждения) и зеленый (все тесты пройдены успешно). Помимо статуса можно увидеть: сообщение об ошибке или предупреждение, если что-то пошло не так; последний коммит и его автора; историю сборок и т.д. В целом интерфейс достаточно информативен и понятен. Помимо этого, travis-ci будет оповещать о проблемах по электронной почте.
Особенности работы сервиса
Интересные факты
Заключение
Travis-ci волей — не волей, вызывает к себе интерес. Учитывая еще тот факт, что в данный момент на нем хостятся довольно крупные и известные проекты, спрос на такие услуги есть. Сервис только набирает обороты и хочется пожелать ему обрести большое сообщество пользователей.
Можно использовать эту статью как пример для быстрого старта.
Я много слышал про Travis CI и давно хотел настроить в нем автоматический запуск тестов, но меня останавливало две вещи:
Потратив пол дня на изучение документации и эксперименты, я настроил тесты и хочу рассказать вам об этом.
Что такое Travis CI
Travis CI — это continuous integration сервис для проектов на Github. Когда вы коммитите что-то в репозиторий, Travis CI может автоматически выполнять разные полезные действия. Например, он может запускать модульные тесты и линтеры кода. Я буду называть эти полезные действия словом «сборка» («build»).
Настройка Travis CI
Первое, что нужно сделать — залогиниться на сайте https://travis-ci.org, используя свой GitHub аккаунт. После этого вы увидите список всех своих репозиториев. Нажмите на переключатель напротив репозитория, для которого нужно включить интеграцию с Travis:
Давайте разберемся, что здесь написано:
Также видим, что тесты упали, т.к. они обращаются к БД, которая им недоступна.
Подключение PostgreSQL
Коммитим измененный файл и пушим на удаленный сервер. Тада. На этот раз тесты прошли успешно!
Tic Tac Toe, часть 7: pytest и Travis CI
Создайте аккаунт на GitHub, если у вас его еще нет. Создайте новый репозиторий с любым названием, например, test-travis.
Авторизуйтесь на Travis CI с помощью аккаунта GitHub. Выполните привязку аккаунта к аккаунту на GitHub. Выберите репозиторий test-travis.
На GitHub добавьте в репозиторий файл .travis.yml со следующим содержимым:
Travis CI автоматически начнет сборку проекта. В Travis CI через Dashboard переходим на страницу сборки проекта, наблюдаем за процессом сборки и смотрим на результат.
Видим, что ни одного теста не было выполнено, поскольку они просто отсутствуют в нашем репозитории.
Добавим тест test_sample.py в наш репозиторий на GitHub. Скопируем его отсюда.
Переходим в Travis CI на страницу сборки проекта и видим, что процесс сборки начался. Тест, как и ожидалось, не прошел.
Исправляем test_sample.py, переходим в Travis CI на страницу сборки проекта, видим, что тест прошел.
Домашнее задание
Попробуйте взять проект из статьи Tic Tac Toe, часть 4: Взаимодействие с бэкендом на Flask с помощью HTTP. Можно просто выполнить форк с этого репозитория: https://github.com/nomhoi/tic-tac-toe-part4. Добавьте какие-нибудь тесты для Python и JavaScript скриптов, добавьте файл .travis.yml. Документация по настройке тестов для Python: https://docs.travis-ci.com/user/languages/python/, для JavaScript: https://docs.travis-ci.com/user/languages/javascript-with-nodejs/. Я тоже попробую и выложу ссылку на репозиторий здесь позже.
Заключение
Чтобы воспользоваться технологией непрерывной интеграции из всех наших телодвижений потребовалось добавить в репозиторий файл .travis.yml, авторизоваться на сервисе Travis CI и выбрать там репозиторий. В дальнейшем будут усилия только по правильной настройке конфигурационного файла .travis.yml.
Если разработчик один, то тесты можно выполнять и на своем локальном компьютере. Но если проект пишется командой, то удобнее выполнять тесты после каждого push’a в общий репозиторий. Тесты будут выполнены системой непрерывной интеграции автоматически после каждого push’a в общий репозиторий.
В следующих статьях рассмотрим Continuous Delivery.
Автоматизация сборки Qt проекта на Windows в Travis CI
Недавно для QtProtobuf я озадачился настройкой босяцкого CI для верификации «запросов на слияние» aka pull requests, ну и конечно для того, чтобы вставить модный бэйдж в README проекта. На выбор были GitHub Actions и Travis CI. Честно скажу, я не задавался целью искать, сравнивать, анализировать, хотелось простоты и быстрого решения совсем несложной задачи. Сначала я разобрался с CI для GitHub Actions, и настроил билд и верификацию юниттестов через docker контейнер. Но ввиду уймы ограничений GitHub Actions оказался попросту непригодным для верификации проекта в Windows. Пришлось обратиться к Travis CI.
На момент написания статьи в Travis CI красавался вот такой дисклеймер:
Windows builds are in early access stage. Please head to the Travis CI Community forum to get help or post ideas.
Это вызывало опасения, поскольку изначально я пытался настроить все через docker-контейнер и подсунуть его в GitHub Actions, но эта затея провалилась из-за ограничений по размеру, типу контейнеров и т.п. в GitHub.
К делу
Для начала работы вам нужно авторизовать Travis CI в GitHub, после чего в настройках вашего профиля появится приложение Travis CI. Что удобно вы можете определить репозитории, к которым Travis CI может иметь доступ:
Следующим шагом будет настройка триггеров Travis CI. Эта процедура уже делается из панели администрирования самого Travis CI, на момент написания статьи были доступны следующие триггеры:
В принципе достойный набор для построения CI.
После выбора триггеров для запуска билдов, необходимо создать .travis.yml, с описанием процедуры построения и, в зависимости от имеющихся триггеров, поместить этот файл в репозиторий. Сразу озадачила разрозненная и несистематизированная документация самого Travis CI касательно .travis.yml, но при желании разобраться можно.
Основная задача, которая стояла — это подготовка окружения для сборки, поскольку сама сборка и верификация это дело CMake.
Описываем процедуру сборки в .travis.yml
Для начала нужно выбрать операционную систему, которая запускается как виртуальная машина на серверах Travis CI, и язык программирования.
language, насколько я понимаю, автоматизирует некоторые шаги если они не указаны явно, но его обязательность для меня загадка. Думал, что без него будет отсутствовать предустановленный MSVC, но во время экспериментов оказалось, что для других языков он тоже пристутствует.
Следующим шагом нужно скачать и установить необходимые зависимости. Для QtProtobuf, такими являются:
И тут Travis CI сильно подсобил. Среди предустановленных пакетов оказался не только Git и MSVC, но и cmake, wget и chocolatey. В прицнипе при наличии chocolatey, дальнейшая установка зависимостей значительно облегчена. Правда, для меня осталось загадкой, почему в chocolatey до сих пор не завезли Qt.
Для начала скачиваем полный инсталлер Qt из официального репозитория:
Делаем установку необходимых зависимостей:
С установкой GoLang и Yasm думаю не должно быть вопросов. А вот запуску инсталлера Qt, я уделю больше внимания.
QtInstallerFramework поддерживает автоматизацию процесса установки путем написания скриптов.
Готовые скрипты для инсталляции той или иной версии Qt достаточно просто гуглятся, я лишь дам ссылку на имеющийся у меня и обращу внимание на выбор компонент для установки:
Здесь я отключаю все checkbox компоненты вызовом widget.deselectAll(); и включаю необходимый для постройки «qt.qt5.5132.win32_msvc2017«. Тут имеются 2 аспекта, которые важны при написании этой процедуры:
Так же в связи с изменениями в политике Qt, необходимо установить логин и пароль для пользователя
И последний важный момент, который я затрону в этом tutorial — это окружение для сборки. Из-за того, что установка зависимостей и сборка происходят в рамках одного shell, после уставновки Go и Yasm в нашем shell нет прописаного PATH до исполняемых файлов. Поэтому необходимо вручную прописать PATH, GOROOT перед простраением:
Еще хочется обратить внимание на то, что в CMAKE_PREFIX_PATH по аналогии необходимо прописать путь до Go и Yasm для корректной работы функции find_program.
Возможно позже я соберусь описать создание docker-контейнера для сборки с Qt на борту.
Как настроить сборку и тестирование для Open Source проекта на Rust под Linux с помощью Travis
30 Июля 2017 • Михаил Панков • обучение • поддержите на Patreon
Как зарегистрироваться на Travis, подключить туда свой проект на Rust и сделать первую сборку.
Содержание
Требования
Настройка простейшего проекта
В качестве примера здесь фигурирует репозиторий простейшей библиотеки hello, состоящей из одной функции и одного теста.
Регистрируемся на Travis
Заходим на Travis. Нажимаем « Sign Up».
Если вы не вошли в свой аккаунт на GitHub, вам предложат войти:
После этого Travis запросит разрешение на доступ к данным на GitHub. Разрешите его.
Если что-то пошло не так:
Добавляем проект
Нажмите « +» над списком проектов в левой части панели управления:
Появится окно добавления проектов. В нём найдите ваш проект и кликните по переключателю для подключения проекта к Travis:
Добавляем.travis.yml
Пушим на GitHub
Весь процесс занимает примерно минуту для простейшего проекта.
Вот как выглядит страница сборки для моей библиотеки hello.
После окончания сборки вам на почту должно прийти письмо с результатом:
Настраиваем кэширование
Добавляем индикатор статуса сборки
Скопированный текст вставляем в README.md в нашем репозитории:
Идём на страницу проекта в GitHub, видим там индикатор:
Готово!
Мы настроили сборку и тестирование проекта на Rust на Travis. Он будет тестироваться на каждый пуш в репозиторий.
Продвинутые возможности
Выбор версии Rust
Так можно указать необходимую версию компилятора:
Тестирование с несколькими версиями
Можно собирать и тестировать проект с несколькими версиями компилятора:
Такая конфигурация последовательно соберёт и запустит тесты на stable, beta и nightly. При этом ошибки во время сборки или тестирования на nightly не приведут к провалу всей задачи на Travis: в индикаторе всё равно будет написано « passing».
Как поменять шаги тестирования
По умолчанию Travis выполняет такие шаги для проектов на Rust:
На этом всё. Успешных сборок!
Другие статьи цикла: