что такое travis yml
Можно использовать эту статью как пример для быстрого старта.
Я много слышал про Travis CI и давно хотел настроить в нем автоматический запуск тестов, но меня останавливало две вещи:
Потратив пол дня на изучение документации и эксперименты, я настроил тесты и хочу рассказать вам об этом.
Что такое Travis CI
Travis CI — это continuous integration сервис для проектов на Github. Когда вы коммитите что-то в репозиторий, Travis CI может автоматически выполнять разные полезные действия. Например, он может запускать модульные тесты и линтеры кода. Я буду называть эти полезные действия словом «сборка» («build»).
Настройка Travis CI
Первое, что нужно сделать — залогиниться на сайте https://travis-ci.org, используя свой GitHub аккаунт. После этого вы увидите список всех своих репозиториев. Нажмите на переключатель напротив репозитория, для которого нужно включить интеграцию с Travis:
Давайте разберемся, что здесь написано:
Также видим, что тесты упали, т.к. они обращаются к БД, которая им недоступна.
Подключение PostgreSQL
Коммитим измененный файл и пушим на удаленный сервер. Тада. На этот раз тесты прошли успешно!
Автоматизация сборки 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 на борту.
Что такое 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 для iOS проектов с открытым кодом
Непрерывная интеграция (continuous integration) — практика разработки, позволяющая добиться большей уверенности в стабильности и корректности работы любого проекта. Проекты с открытым кодом — не исключение.
Примерно два месяца назад, в апреле 2013 года комапания Sauce labs объявила о поддержке iOS / Mac для CI-сервера Travis. Сам сервис существует уже довольно давно, и пользуется довольно большой популярностью в open-source community благодаря поддержке большого количества языков и удобству использования. Cервис бесплатен для любого пользователя github и открытых репозиториев. На Хабре уже имеется пост о сервисе и его настройки для тестирования Ruby-проектов, поэтому в этой статье я хотел бы рассказать о более специфической стороне сервиса — настройке автоматической сборке билдов iOS проектов на Travis-CI. Основным фокусом этой статьи будет связка CocoaPods + Cedar + Travis CI, однако я постараюсь рассказать немного и о других связанных с темой вещах.
Итак, начнем.
Имеем проект на github, который не имеет никакого отношения к данной статье, однако хочет иметь отношение к Travis CI. На проекте используются CocoaPods, все тесты написаны с помощью фреймворка Cedar.
Шаг первый. Подключение github-репозитория
Заходим на сайт сервиса, логинимся с помощью github аккаунта. Заходим в настройки профиля, и включаем репозиторий, на котором мы хотим гонять билды и тесты.
Шаг второй. Настройка конфигурационного файла
Первым делом необходимо задать язык программирования, для которого будет осуществляться билд.
Следующий шаг — настройка всех необходимых гемов, и зависимостей для проекта. Имеются следующие шаги работы воркера Travis:
В частности, для запуска тестов на симуляторе мы будем использовать гем ios_sim. Удобно, что Travis имеет предустановленный Homebrew, так что установка гема имеет следующий вид
Забежим немного вперед. Недостаточно просто запустить билд на симуляторе, важно еще и получить результаты Cedar — тестов. В этом нам поможет гем ios_ci, позволяющий сбилдить проект, запустить его на симуляторе, и получить результаты тестирования. Ставим гем:
Следующий шаг настройки опционален, и связан с конкретной структурой папок выбранного проекта. Файл проекта XCode находится не в корневой директории репозитория, а в директории Example. Поэтому изменяем текущую директорию на директорию с проектом:
Последним шагом настройки должна была быть установка CocoaPods, однако Travis делает это автоматически, если находит в директории Podfile, так что настройка завершена, можно переходить к сборке.
Шаг третий. Билд проекта и запуск тестов
Переходим к скрипту, который будет непосредственно гонять наши тесты. Нужно понимать, что это не обязательно должен быть седаровский скрипт, или команда make. На самом деле, единственное требование, которое Travis CI выдвигает к шагу script — он должен вернуть значение. 0 — успех, все остальное — фейл. Соответственно можно собирать проект так, как вам это необходимо, и можно использовать любой тестовый фреймворк, включая встроенный OCUnit.
Команда для сборки проекта и прогона тестов будет выглядеть достаточно лаконично
Шаг четвертый. Профит
Все, что осталось сделать, это сделать коммит в одну из веток, и запушить изменения на github. Travis-CI автоматически запланирует билд, и через минуту-две начнет собирать проект. Если все пройдет успешно — статус станет зеленым, если нет — красным. Одновременно на почту отправится сообщение об успешности или неудаче сборки.
Дополнительные плюшки Travis-CI
1. Возможность выбрать ветки репозитория, для которых будет запускаться билд.
Таким образом, Travis будет собирать билды только для коммитов, сделанных в эти две ветки. Аналогичным образом можно добавлять ветки в черный список:
2. Возможность автоматического запуска билдов для пулл реквестов. Более того, статус билда будет отображаться прямо в пулл реквесте на страничке github.
Бейджик представляет из себя ничто иное, как ссылку следующего вида
Данная статья показывает лишь необходимый минимум для настройки билдов на Travis-CI. Возможности данного сервиса намного больше, например известный фреймворк RestKit использует Travis не только для сборки билдов и тестов, но также и для генерации документации с помощью appledoc.
Спасибо за внимание, и удачных open-source проектов!
Travis-CI: что, почему, как
Travis CI облегчает работу в команде над программным проектом с помощью автоматизированных сборок. Эти сборки запускаются автоматически, когда каждый разработчик проверяет свой код в хранилище. В этой статье мы рассмотрим, как легко интегрировать Travis CI с нашим проектом, который размещен на Github. Благодаря автоматизации, уведомлениям и тестированию мы можем сосредоточиться на нашем кодировании и создании, а Travis CI выполняет тяжелую работу по непрерывной интеграции!
Привет Тревис и CI!
Прежде чем мы начнем с того, как мы можем интегрировать Travis с нашим проектом, будут полезны следующие предпосылки:
В основе использования Travis лежит концепция непрерывной интеграции (CI). Допустим, мы работаем над одной функцией, и после того, как мы закончили кодирование, мы, как правило, создадим проект так, чтобы создать исполняемый файл, а также другие файлы, необходимые для запуска приложения. После того, как сборка завершена, передовые практики включают в себя запуск всех тестов, чтобы убедиться, что все они пройдены, и все работает как положено.
Последний шаг — гарантия того, что все, что мы написали, действительно работает даже после того, как мы интегрируем его в основной код. На данный момент мы строим и тестируем снова. Если интегрированная сборка завершится успешно, мы можем считать, что эта функция полностью реализована. Travis CI автоматизирует этот точный шаг — запускает сборку и тестирование при каждой интеграции с основной веткой, другими ветвями или даже запросом извлечения, сокращая время обнаружения потенциальной ошибки интеграции.
В следующих разделах мы возьмем простой проект и запустим неудачную сборку, исправим ее и затем передадим. Мы также увидим, как Travis CI легко работает с запросами Github.
Travis Interface
Когда мы попадаем на главную домашнюю страницу, мы также видим «занятость» многих проектов с открытым исходным кодом, проходящих автоматическую сборку. Давайте разберем интерфейс и разберемся с различными частями: