Buildbot vs Jenkins

Ну ты сравнил. Дженкинс - готовая вундервафля с кучей плагинов для всего включая минет и приготовление капучино. Билдбот - небольшая тулзень, с которой чо хочешь - то и твори. Билдбот имеет смысл только если собирать много и интересно, а поддерживать будет специально обученный человек. Дженкинс - натяпляпать чтобы работало, саппортить потом любая обезьяна с правами админа может

Если выражаться менее цветисто и не упоминать кофе и секс, сказанное сводится к «у Jenkins лучше webgui и больше плагинов». Спасибо, но это я и сам знаю.

И да, вострег, залогинься.

дженкинс скриптуется костыльно, в отличие от...

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

Про админов, которые могут настроит CI на дженкинсе — все враки, они не умеют в параметризацию и тупо копипастят

По моему скромному опыту, скрипты для buildbot (точнее, списки команд для BuildFactory) тоже проще всего писать копипастом.

Если выражаться менее цветисто и не упоминать кофе и секс, сказанное сводится к «у Jenkins лучше webgui и больше плагинов».

нет. сводится к тому, что дженкинс - это во-первых стандарт, который осиливает кто угодно за 3 часа, а во-вторых - документированный и пригодный к использованию из коробки. билдбот - гораздо сложнее.

Спасибо, но это я и сам знаю.

хочешь конкретных ответов - задавай более конкретные вопросы

И да, вострег, залогинься.

чего ради?

дженкинс - это во-первых стандарт,

Стандарт где - в жабном ынтерпрайзе? Не заводит.

который осиливает кто угодно за 3 часа

Включая скриптование на Groovy или это отдельные 3 часа?

во-вторых - документированный и пригодный к использованию из коробки

Да. Только на билдслейве должна быть Java 7. Или уже Java 8?

Ладно, мне неинтересен флейм Jenkins vs Buildbot. Мне интересны военные истории о любом из них.

buildbot - некрасивенький, но свою работу делает, позволяет оченьм ного странного и необычного, сам лёгкий по потреблению ресурсов. Jenkins - на жабе, больше заточен на жабу, но умеет также много всего. Возможности скриптования у него хуже и местами костыльнее чем у buildbot, но зато он очень легко осваивается не-программистами, они даже могут подкорректировать билд и проверить результаты тестов. То, что буду смотреть только я, редко меняется, гоняется там, куда не влезает jenkins - гоняю buildbot, он мне значительно проще в плане быстро запустить CI. Там где нужно напоказ, особенно с настоящими тестерами и сложнозависимыми билдами, когда я не хочу уже разбираться, что там у людей в голове - jenkins.

Но надо понимать, что по сути скрипт и там и там, сложная задача сложна одинаково. Нетривиальное проще в buildbot впихнуть, но jenkins при определённоё упёртости может тоже. Ограничения jenkins часто удаётся закрыть плагинами, когда как в buildbot проще подправить код. Я ещё не сталкивался с билдом, который можно было бы запустить под buildbot и нельзя под jenkins, и наоборот. Часто это просто вопрос затрат времени. У jenkins ещё то преимущество, что он легко понятен той категории программистов, которые уже почти менеджеры - можно скинуть с себя лишний геморрой, повесив билды на такого человека, там получается почти идеальное сочетание. Просто ЦУ интерфейса jenkins'а как раз такая.

Сложности с jenkins у меня были в основном тогда, когда нужно было извлекать разные метаданные (запихнуть автоматом сгенерированные ReleaseNotes в билд, где нужно было подсунуть список пофикшенных багов из трех разных багтрекеров, список заимлеменченных фич, версию из SCM), оно как-то не слишком гибко в этом месте, пришлось генерить костыли, но в общем не то чтобы совсем долго. У buildbot'а другие трудности - если есть много данных, получаемых во время билда и заранее неизвестных, синтаксис скрипта становится черезвычайно инопланетянским, и чреватым большим количеством ошибок. Поэтому тоже бывает проще плюнуть и запилить костыль, но реже, чем с jenkins.

Там где нужно напоказ, особенно с настоящими тестерами и сложнозависимыми билдами

А что, сложнозависимые билды в Buildbot делать труднее? Я пока не дошел до них, но вроде Triggered scheduler есть, что еще надо?

У buildbot'а другие трудности - если есть много данных, получаемых во время билда и заранее неизвестных, синтаксис скрипта становится черезвычайно инопланетянским

Интересно. Можно пример?

Buildbot vs Jenkins

Смотря что за проект. Если жабамирок и работа мышкой – дженкинс самое оно. BB для таких крутых парней.
https://build.chromium.org/p/chromium/waterfall

Я совершенно точно не из жабамира. И я не просто крут, я вообще вертикален.

И я не просто крут, я вообще вертикален.

Ну вот. Да еще и «старый быдлокодер». Смело бери buildbot :)

Я и взял, но потому, что мне Jenkins тупо не подходит пол своим требованиям. Теперь мне интересно, что я выиграл, а что проиграл.

Сложнозависимые = билд A зависит от B при условии, что в процессе сборки билда B прогон теста показал изменение в модуле таком-то, при условии что манагер в интерфейсе выбрал нужную галочку. Это не значит что в buildbot такое нельзя делать - просто при определенном уровне сложности проще пользоваться интерфейсом jenkins, чем упихать всё в скрипт, особенно если оно меняется часто. Да и интерфейс таков, что туда можно посадить человека, у которого соответствующим образом устроены мозги.

По поводу данных - я не хочу свои волосатые скрипты на свет выводить, но там реально неудобно, когда пара сотен переменных набегает (например, версии подпроектов, использованных при сборке текущего билда, это самое мучительное, пожалуй, ну или по текущему чекауту понять, что пересобирать, а что нет, и дёргать зависимые билды при этом в нужной последовательности), и это не просто данные, а по ним нужно принимать решение в процессе билда.

Теперь мне интересно, что я выиграл, а что проиграл.

Выиграл гибкость, проиграл поддержку. Хотя да, насчет гибкости все относительно и опять же зависит от сложности. Если у вас там кучи ветвистых зависимостей между проектами и нужно все это собирать, параллельно тестировать и прочее и прочее, то я даже не знаю что будет лучше – bb или дженкинс.

что мне Jenkins тупо не подходит пол своим требованиям

А чем, например?

Java 7 (и скоро Java 8) на сборочной машине. Ну и скриптинг на Groovy - я его тупо не знаю.

jenkins норм, buildbot не использовал, сложные зависимости для сборки не нужны. попутно к тебе вопрос - не смотрел, случайно, на bazel, pants, buck или baserock?

не смотрел, случайно, на bazel, pants, buck или baserock?

Нет. Но, насколько я вижу, всё это замены make (кроме baserock), а baserock - вообще инструмент сборки дистров (мы используем Yocto).

У дженкинса есть javadoc. Код плагинов на гитхабе. Это всё облегчает автоматизацию сложного взаимодействия дженкинс-проектов на грувях.

Попробуй http://readme.drone.io/usage/overview/

Попробуй http://readme.drone.io/usage/overview/

Судя по

Continuous Integration for Github and Bitbucket

GET STARTED FOR FREE

это какой-то анальный зонд для поколения github-программистов. Пусть горит в топке локалхоста.

Как-то мучался тем же вопросом. Моё мнение — этот buildbot какой-то страх и ужас выросший из чьей-то наколенной поделки (это не значит что он не работает).

Долго сравнивали jenkins и buidbot. В принципе, есть работающее ci на женкинсе. Но в дальнейшем вознамерились перетечь на билдбот, поскольку что с женкинсом хорошо только до тех пор, пока твои нужды закрыты имеющимися плагинами. А если нужно шаг-влево-шаг-вправо, то попадаешь на ковыряние в жавакоде, и оказалось, что почему-то никто не рвётся туда погружаться.

У меня есть. Зависит от задач. Мне требовалось собирать много зависимых друг от друга rpm и deb пакетов под разные версии OS. В итоге, мы пришли к мысли, что лучше поднять Koji, потому что параллельный createrepo ведет себя просто отвратительно, зависимости отслеживать сложно, а мой кастомный костыль (чтобы переменные окружения задавать) к Jenkins плагину с директориями поддерживать никто не хочет.