Комментарии 17
Почему Jenkins не вошёл в обзор? Вообще, честно говоря, обзор ни о чём. Например, нам нужен CI-сервер для кроссплатформенного C++ приложения с кучей зависимостей. И как ваш обзор нам поможет в выборе?
На самом деле мы давно пользуемся какой-то древней версией Jenkins и нам хватает, но вот лично мне хотелось бы узнать об альтернативных open source решениях, хотя сомневаюсь, что среди всех этих модных CI, основанных на docker-контейнерах, найдётся что-то удобнее и гибче чем наш дубовый Jenkins.
+10
сомневаюсь, что среди всех этих модных CI, основанных на docker-контейнерах, найдётся что-то удобнее и гибче чем наш дубовый Jenkins
не пробовали обновлять софт? :) 2.0 jenkins очень даже гибкий, нынче пайплайны в тренде https://jenkins.io/doc/book/pipeline/ Контейнеры (и еще кучу всего) он тоже умеет, например https://wiki.jenkins-ci.org/display/JENKINS/Docker+Slaves+Plugin
-1
Jenkins — эталон гибкости в Open Source CI. Drone и Gitlab CI — в разы проще для освоения, но и умеют в разы меньше — весь их функционал можно реализовать на Jenkins абсолютно без проблем.
0
Что умеет Jenkins, чего не умеет, например, Gitlab CI?
+1
— Копирование артефактов от других сборок. Есть репозиторий с библиотекой, есть репозиторий с основным приложением — нужно скопировать последнюю собранную библиотеку.
— Build Parameters и ручной ребилд — нужно собрать инсталлятор, в который войдут несколько приложений, которые прошли ручное тестирование. При этом последний успешный артефакт нас не устраивает — мы выпускаем патч на софт полугодичной давности.
— Любая логика — если сборка для тега XXX есть — скопировать ее артефакты, если ее нет — запустить сборку и скопировать ее артефакты.
Плюс я не уверен, что в Gitlab CI есть matrix builds (собрать под Windows, Linux, OSX пакеты example, example-debug, example-some-feature, при этом под Windows не собирать example-debug, а под OSX не собирать example-some-feature). Естественно, если речь про C++ проект — надо все собирать под Windows, Linux и OSX соответственно.
— Build Parameters и ручной ребилд — нужно собрать инсталлятор, в который войдут несколько приложений, которые прошли ручное тестирование. При этом последний успешный артефакт нас не устраивает — мы выпускаем патч на софт полугодичной давности.
— Любая логика — если сборка для тега XXX есть — скопировать ее артефакты, если ее нет — запустить сборку и скопировать ее артефакты.
Плюс я не уверен, что в Gitlab CI есть matrix builds (собрать под Windows, Linux, OSX пакеты example, example-debug, example-some-feature, при этом под Windows не собирать example-debug, а под OSX не собирать example-some-feature). Естественно, если речь про C++ проект — надо все собирать под Windows, Linux и OSX соответственно.
+1
В Gitlab CI обещают улучшить работу с артефактами — можно будет загружать артефакты от предыдущих задач в конвейере, наверное, будет апи, с помощью которого можно будет делать многое из того, что вы описываете. Ручного запуска билдов, насколько я знаю, нет. А build matrix есть, но она задается вручную перечислением задач.
С другой стороны, в Jenkins довольно тяжело работать с docker. А без него сложно обеспечить изоляцию билдов — например, на одном воркере тестировать проект с разными версиями python и mysql одновременно. И с автоматическим созданием воркеров в облаках непросто.
С другой стороны, в Jenkins довольно тяжело работать с docker. А без него сложно обеспечить изоляцию билдов — например, на одном воркере тестировать проект с разными версиями python и mysql одновременно. И с автоматическим созданием воркеров в облаках непросто.
0
> С другой стороны, в Jenkins довольно тяжело работать с docker.
Я всеми руками за использование docker в CI, и в Jenkins есть два очень простых и правильных способа работы с Docker:
— Docker Custom Build Environment
— Docker Pipeline Plugin
Для сборки есть Docker Build and Publish Plugin
> И с автоматическим созданием воркеров в облаках непросто.
Jenkins умеет автоматически поднимать слейвы в облаках по требованию, например EC2 Plugin. Хотя я привык создавать машины руками и накатывать окружение (JVM и docker) через puppet.
Я всеми руками за использование docker в CI, и в Jenkins есть два очень простых и правильных способа работы с Docker:
— Docker Custom Build Environment
— Docker Pipeline Plugin
Для сборки есть Docker Build and Publish Plugin
> И с автоматическим созданием воркеров в облаках непросто.
Jenkins умеет автоматически поднимать слейвы в облаках по требованию, например EC2 Plugin. Хотя я привык создавать машины руками и накатывать окружение (JVM и docker) через puppet.
+1
хотелось бы узнать об альтернативных open source решениях, хотя сомневаюсь, что среди всех этих модных CI, основанных на docker-контейнерах, найдётся что-то удобнее и гибче чем наш дубовый Jenkins
Еще есть GoCD by ThoughtWorks. Это уже Continuous Delivery. OpenSource. И позволяет создавать более гибкие пайплайны в сравнении с Jenkins 2.
0
СoncourseCI ещё стоит упомянуть
+2
Встроенной поддержки кэша не предусмотрено
Вы в этом уверены? Поддержки s3 из коробки нет, но, насколько я помню, в конфиге есть секция cache
в которой можно задать директории, которые нужно сохранять между билдами. Например для сохранения node_modules
или виртуального окружения Python.
0
Для версии 0.5 — http://readme.drone.io/questions/how-to-cache-artifacts/
0
Я использую QuickBuild для сборки проектов сразу под три платформы. Перепробовал все найденные решения. Большинство не имеет агентов под винду; Jenkins — страшный и сложный. Вероятно, при должно терпении, там можно найти плагины и все настроить, но я два раза пробовал и бросал. TeamCity — подходит под мои задачи, но не очень гибкий и тяжелый в плане ресурсов сервера. А у QuickBuild нет проблем с поддержкой трех систем и довольно легко было настроить, чтобы собирать три бинарника из одного проекта, а потом делать из них один архив. И очень гибкий с поддержкой скриптов во всех полях.
0
Оно в ядре и не нужно. Это можно быстренько сделать на коленке. Можно использовать s3 или просто машинку с openssh. В моем случае этим целям служит отдельный контейнер с caddy (+ модуль upload)
образ cache содержит простой скрипт:
pipeline:
cache_get:
image: ..../cache
path: /drone/.m2
retrieve: m2
build:
image: .../maven
commands:
- mvn install -q
.....
cache_put:
image: .../cache
path: /drone/.m2
store: m2
образ cache содержит простой скрипт:
#!/bin/sh
store()
{
cd "$1"
if tar cz .| curl -u $USER:$PASS -T - $URL/cache/$2.tar.gz
then echo "$2 stored successfully"
fi
exit 0
}
retrieve()
{
if curl -u $USER:$PASS $URL/cache/$2.tar.gz | tar zx -C $1
then echo "$2 retrieved successfully"
fi
exit 0
}
if [ ! -d "$PLUGIN_PATH" ]; then
mkdir $PLUGIN_PATH
fi
if [ -n "$PLUGIN_STORE" ]; then
store $PLUGIN_PATH $PLUGIN_STORE
exit 0
fi
if [ -n "$PLUGIN_RETRIEVE" ]; then
retrieve $PLUGIN_PATH $PLUGIN_RETRIEVE
exit 0
fi
0
А вот еще решение с хранением кеша на выполняющем хосте: https://github.com/Drillster/drone-volume-cache
Но оно требудет привилегированного контейнера и подписанного drone.yml
Но оно требудет привилегированного контейнера и подписанного drone.yml
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Опыт использования self-hosted continuous integration систем