Comments 15
1) будете ли вы еще использовать Jenkins или теперь только Travis
2) какой самый сложный случай автоматизации сборки?
3) насколько я понял он не работает под windows
4) можно ли сделать 2 сборки проекта, чтобы проверить самообновление одну на другую (это, например, если мы делаем пользовательское приложение с самообновлением)
5) если у вас 20 проектов, то можно ли сделать какой-нибудь отчет, где собраны ссылки на
эти проекты с указанием версии и даты сборки
  1. Jenkins — не буду утверждать на 100%, но скорее всего нет.
  2. Мы используем Drone несколько месяцев и на сегодняшний день наша сборка очень простая: запустить тесты, сбилдить и запаблишь в регистри десяток контэйнеров, запустить Ansible скрипт, отправить нотификацию в слак. С более сложными сборками опыта нету, но, как мне кажется проблем не должно возникнуть. Drone, в целом, стимулирует делать сложное простым.
  3. Под windows действительно не работает. Попытки были, но они явно не в фокусе разработчиков.
  4. Да, не вижу тут проблем. Либо через matrix builds, либо просто два отдельных шага.
  5. Нет, такой возможности нету, но если есть сильная нужда — то отчет можно построить напрямую из PostreSQL, разобравшись в SQL схеме Drone CI.
А можно выложить какой-нибудь скриншот — как выглядит домашняя страница системы сборки, что вы видите каждый день?

Для меня страницы вида https://jenkins-debian-glue.org/img/jenkins_jobs.png выглядят перегруженными, тем более, если проектов 20

Минималистичней Drone CI интерфейса не встречал. Он выполняет всего несколько функций:


  1. Отображение всех ваших репозиториев с github на страничке /account.
  2. Отображение всех проектов (на картинке слева), для которых включена CI.
  3. Отображение коммита и статуса запуска билда (на картинке по центру)
  4. По нажатию на коммит отображаются логи запуска билда.

Вот скриншот. Ой, кажется нада срочно чинить тесты :)

  • Можно ли интегрировать не с гитхаб, а с локальным гитлаб?
  • Можно ли создавать разные секреты/переменные с одни именем, но разными значениями для разных веток?
  • Пробовали ли как-то тестировать/запускать два интегрированных сервиса в разных репозиториях в рамках одного проекта?
  1. поддерживается интеграция с GitHub, Bitbucket, Bitbucket Server, GitLab, Gogs, если вы сможете смоделировать API и WebHook одной из систем, думаю можно обмануть Drone, другой вариант писать свой плагин на go;
  2. да можно, для разных веток, для разных событий (push, pull_request, ...) можно иметь разные значения;
  3. не совсем понял, но drone похоже на docker-compose с точки зрения запуска окружения в рамках которого производится тестирование и сборка, соотвественно, если вашу задачу можно решить через docker-compose для тестирования, то и через Drone можно.

Существенным изменением при переходе с 0.4 на 0.5 версию в Drone был отказ от доступа к локальному диску для хранения кеша.


Так, мы используем его для тестирования Symfony проекта, с большим количеством зависимостей, и вот composer install на каждый коммит выполняется долго. В предыдущей версии, можно было кешировать скаченные пакеты, в новой версии это надо "мудрить".

Отказ от локального монтирования томов был связан с появлением агентов, которые могли находиться на разных машинах. Есть вот такое решение http://plugins.drone.io/drillster/drone-volume-cache/, если нужно уметь работать с разными агентами на разных серверах, то можно использовать в связке с glusterfs или с другими решениями типа ceph.

Лучше тогда использовать minio который где то в соседних темах обсуждался. Он совместим по протоколу с S3, а значит можно использовать штатный плагин для drone plugins/s3

Обсуждение использования S3-совместимого хранилища для кешей было, но так и не реализовано. На данный момент есть такое решение в виде sftp клиента, чем мы у себя и пользовались.
Jenkins на самом деле замечательно автоматизируется при помощи jenkins-job-builder. Pipeline-as-a-Code у него также есть. Как раз начал его смотреть, но пока особых плюсов по сравнению с JJB не наблюдаю.
каждый шаг вашего билда может быть по-настоящему изолированным и работать исключительно в Docker контейнерах

Wow, вы меня очень заинтересовали. Скажите, пожалуйста, а как мне осуществить «по-настоящему изолированный этап сборки в докере», если этот этап включает в себя интеграционное тестирование, кода, который использует iDRAC сервера для конфигурации его на загрузку по PXE, запуск на этом сервере комплекта виртуальных машин с PCI-passthrough GPU-адаптеров и аппаратную акселерацию со стороны сетевых адаптеров"?

У меня ощущение, что вы пытаетесь продать лобзик лесорубу.

Ха-ха, про лобзик лесорубу — это шикарно. Спасибо за коментарий!


В докере достаточно проблематично запускать виртуальные машины, поэтому интеграционное тестирование такого масштаба врятли будет изолированным (в статье мы, кстати, тоже отказались от изоляции при интеграционном тестировании). Этапы же сборки/билда самого софта — могут быть абсолютно изолированными, если вы можете запустить их в Docker контейнере.


В целом, я думаю Вы со мной согласитесь, не бывает софта на все случаи жизни. Drone CI — не исключение. Перед тем как начать использовать нужно попробовать и оценить применимость для конкретного софта, окружения и решаемой задачи.


Мы Drone CI не продаем, просто поделились опытом, который нам показался интерестным и необычным, и попытались убрать боль адаптации для тех, кому данное решение подходит.

Демагогия получается. Сборкой называется:


  1. Cборка кода (компиляция исходного кода и построение дистрибьютива). Это то, что я имел ввиду.
  2. Сборка (build) — включает в себя сборку кода + запуск тестов + публикация отчета.

Судя по википедии, сборка (build) состоит из:


получение исходного кода из репозитория;
сборка проекта;
выполнение тестов;
развёртывание готового проекта;
отправка отчетов.

Only those users with full accounts are able to leave comments. Log in, please.