Непрерывная интеграция (CI) для GitHub проектов на С/C++ с CMake-сборкой

[bustEXZ]

Вроде как докер растет в сторону и Windows, даже офф софтина появилась (правда внутри себя работает через прослойку, но смотрится достаточно удобно и незаметно) https://www.docker.com/products/docker-toolbox

[vovkos]

Тут дело даже не в том, запускается или нет Docker на Windows или Mac OS X (как вы верно отметили, да, запускается). Проблема в том, что Travis CI предоставляет Docker-контейнер для сборки только под Linux, а AppVeyor вообще не даёт возможности выбирать между полновесной виртуальной машиной и Docker-контейнером.

Но это, на мой взгляд, и не важно. Выигрыш всего в минуту (!) в таком длительном, да и, чего уж там, совсем не критичном по времени исполнения процессе, как непрерывная интеграция, просто не стоит того, чтоб с ним заморачиваться.

[4144]

Travis Ci это самый медленный сервис среди Gitlab Ci, Semaphore Ci, Circle Ci.
Если у вас всего несколько билдов, то это не большая проблема. А если их много, лучше смотреть на что-то другое чем Travis Ci.

[vovkos]

Поправьте меня, если ошибаюсь, но беглый осмотр выявил несоответствие списку требований, сформулированных в начале:

• GitLab CI бесплатен только если проект хостится на GitLab
• Semaphore CI не поддерживает Mac OS X
• Circle CI не бесплатен для Mac OS X

На самом деле, при выборе сервисов я прежде всего просканировал, что в основном используют opensource разработчики, хостящиеся на GitHub — с большим отрывом лидирует Travis и AppVeyor.

В принципе, производительность Travis меня вполне устраивает — как мне кажется, CI далеко не является критической по времени задачей. А вот что вполне могло бы заставить меня мигрировать на другой сервис, так это наличие более широкого спектра платформ для сборки/тестирования: Ubuntu посвежее, Arch, Fedora, и т.д.

Не подскажете, есть ли такие?

[bustEXZ]

* Отвечайте людям кликнув на «Ответ», иначе вы не создаете ветку общения с пользователем, не удобно читать и не понятно кому будет адресован ваш ответ. Спасибо

[vovkos]

Ваша правда, мой косяк.

Акелла промахнулся — дважды! ;) На хабре окошко с редактором находится сразу за последним комментарием, отчего складывается впечатление, что отвечаешь на него. А перенести комментарий после создания уже нельзя.

[4144]

Gitlab CI беспланет на любом gitlab хостинге или собстенном сервере с gitlab. Деньги начинаются если вы сами хостите Gitlab большей ревизии чем CE.

Все эти CI сервисы, включая Travis Ci поддерживают docker. Т.е. если вам надо, вы можете запускать любой контейнер, который найдете на docker hub, или дополнительно с gitlab хостинга, если вы используете gitlab ci.
И выполнять в нем все что вам угодно.

Я использую все эти CI за исключением appveyor. Репозиторий миррорится с gitlab.com на github.com

CI с gitlab.com самый быстрый, но не стабильный. Часто он тормозит или вообще не работает.
На остальных сервисах иногда возникают tmeout'ы.

MacOS поддерживается только Travis и если использовать свой раннер Gitlab CI (т.е. надо свой хост с macos). Платные варианты не рассматриваю.

[nick_volynkin]

Репозиторий миррорится с gitlab.com на github.com — а это интересно, можно посмотреть на пример? Вы пулл/мерж-реквесты принимаете там и там?

[4144]

В данном случае я делаю push во все копии скриптом, т.к. их больше 2.
Но для просто копирования, в gitlab есть система копирования. Она кажется раз в сутки подтягивает данные.

Пулл реквесты предпочитаю принимать в gitlab, но можно и там и там. Т.к. синхронизация идет с локального компьютера.

Пример скрипта? Добавлены remot'ы на все репозитории.
Далее при запуске скрипта ему передается название бранча или на пример --tags.
И скрипт выполняет последовательно команды для всех репозиториев-клонов: git push REMOTENAME $1

Т.о. образом можно одной командой пушить одну ветку или теги. ./script master или ./script --tags

Можно было не использовать скрипт, но прописать все клоны в origin репозитория одновренно, но тогда могут быть некоторые проблемы. Если какая-то из копий выйдет из строя, то push может остановиться на пол пути. Также проблема будет с pull из этих веток.

[nick_volynkin]

Я имел в виду не пример скрипта, а пример двух зеркалируемых репозиториев с реквестами в каждом. Впрочем, настройки не были бы видны стороннему посетителю.

А не бывает случаев, когда master случайно поменяли и на гитхабе, и на гитлабе, например там и там приняли по одному реквесту? Или вы принципиально мержите всё на своей машине и синхронизируете с помощью того самого скрипта?

(только сейчас увидел ваш ответный комментарий)

[4144]

Да я предпочитаю делать все в локально или брать за основу master из gitlab репозитория.
Пушить в master может не очень много людей, и все только в gitlab репозиторий.

Github pull requests не могут нормально объединяться (merge) в любом случае. они портят визуально историю.

Т.е. сначала я делаю git pull --rebase для gitlab репозитория, потом скрипт делает push во все репозитории. Если надо, можно вручную можно смержить pull request из github.

[dgrees]

Много воды уже утекло. Делал тут CI на AppVeyor, в итоге на сегодняшний день процесс таков: делаем шаги отсюда www.appveyor.com/docs, на шаге 4 заходим в настройки проекта, выставляем всё что нужно, хотя бы примерно. Далее можно сгенерить .yml файл, и его уже докурочивать (если нужно) и отписать, вместе с кодом бейджика, который также доступен в настройках.