Комментарии (17)

1. 

   iroln

   03.01.2017 12:27

   #9994296

   +10

   Почему Jenkins не вошёл в обзор? Вообще, честно говоря, обзор ни о чём. Например, нам нужен CI-сервер для кроссплатформенного C++ приложения с кучей зависимостей. И как ваш обзор нам поможет в выборе?

   
   

   На самом деле мы давно пользуемся какой-то древней версией Jenkins и нам хватает, но вот лично мне хотелось бы узнать об альтернативных open source решениях, хотя сомневаюсь, что среди всех этих модных CI, основанных на docker-контейнерах, найдётся что-то удобнее и гибче чем наш дубовый Jenkins.

   
   

   1. 

      kazar

      03.01.2017 15:21

      #9994506

      -1

      сомневаюсь, что среди всех этих модных CI, основанных на docker-контейнерах, найдётся что-то удобнее и гибче чем наш дубовый Jenkins

      
      не пробовали обновлять софт? :) 2.0 jenkins очень даже гибкий, нынче пайплайны в тренде https://jenkins.io/doc/book/pipeline/ Контейнеры (и еще кучу всего) он тоже умеет, например https://wiki.jenkins-ci.org/display/JENKINS/Docker+Slaves+Plugin

      
      

      1. 

         gunya

         03.01.2017 15:30

         #9994530

         пайплайнам сто лет в обед — в 2.0 их просто включили в стандартную поставку, плюс заопенсорсили Pipeline Stage View

   
   

   1. 

      gunya

      03.01.2017 15:25

      #9994520

      Jenkins — эталон гибкости в Open Source CI. Drone и Gitlab CI — в разы проще для освоения, но и умеют в разы меньше — весь их функционал можно реализовать на Jenkins абсолютно без проблем.
      

      
      

      1. 

         lewbor

         04.01.2017 06:45

         #9995510

         +1

         Что умеет Jenkins, чего не умеет, например, Gitlab CI?

         
         

         1. 

            gunya

            04.01.2017 14:20

            #9995862

            +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 соответственно.

            
            

            1. 

               lewbor

               04.01.2017 14:52

               #9995914

               В Gitlab CI обещают улучшить работу с артефактами — можно будет загружать артефакты от предыдущих задач в конвейере, наверное, будет апи, с помощью которого можно будет делать многое из того, что вы описываете. Ручного запуска билдов, насколько я знаю, нет. А build matrix есть, но она задается вручную перечислением задач.
               С другой стороны, в Jenkins довольно тяжело работать с docker. А без него сложно обеспечить изоляцию билдов — например, на одном воркере тестировать проект с разными версиями python и mysql одновременно. И с автоматическим созданием воркеров в облаках непросто.

               
               

               1. 

                  gunya

                  04.01.2017 15:32

                  #9995986

                  +1

                  > С другой стороны, в Jenkins довольно тяжело работать с docker.
                  
                  Я всеми руками за использование docker в CI, и в Jenkins есть два очень простых и правильных способа работы с Docker:
                  — Docker Custom Build Environment
                  — Docker Pipeline Plugin
                  
                  Для сборки есть Docker Build and Publish Plugin
                  
                  > И с автоматическим созданием воркеров в облаках непросто.
                  
                  Jenkins умеет автоматически поднимать слейвы в облаках по требованию, например EC2 Plugin. Хотя я привык создавать машины руками и накатывать окружение (JVM и docker) через puppet.

   
   

   1. 

      aenesterov

      03.01.2017 23:15

      #9995212

      хотелось бы узнать об альтернативных open source решениях, хотя сомневаюсь, что среди всех этих модных CI, основанных на docker-контейнерах, найдётся что-то удобнее и гибче чем наш дубовый Jenkins

      
      
      Еще есть GoCD by ThoughtWorks. Это уже Continuous Delivery. OpenSource. И позволяет создавать более гибкие пайплайны в сравнении с Jenkins 2.

1. 

   w32blaster

   03.01.2017 12:49

   #9994314

   +2

   СoncourseCI ещё стоит упомянуть

1. 

   m1kola

   03.01.2017 13:50

   #9994384

   Встроенной поддержки кэша не предусмотрено

   Вы в этом уверены? Поддержки s3 из коробки нет, но, насколько я помню, в конфиге есть секция cache в которой можно задать директории, которые нужно сохранять между билдами. Например для сохранения node_modules или виртуального окружения Python.

   
   

   1. 

      lewbor

      03.01.2017 15:30

      #9994532

      Для версии 0.5 — http://readme.drone.io/questions/how-to-cache-artifacts/

      
      

      1. 

         m1kola

         03.01.2017 19:41

         #9994912

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

         
         

         1. 

            steban

            04.01.2017 19:03

            #9996266

            Промахнулся с веткой. мой ответ про кеш ниже.

1. 

   pronvit

   04.01.2017 06:30

   #9995496

   Я использую QuickBuild для сборки проектов сразу под три платформы. Перепробовал все найденные решения. Большинство не имеет агентов под винду; Jenkins — страшный и сложный. Вероятно, при должно терпении, там можно найти плагины и все настроить, но я два раза пробовал и бросал. TeamCity — подходит под мои задачи, но не очень гибкий и тяжелый в плане ресурсов сервера. А у QuickBuild нет проблем с поддержкой трех систем и довольно легко было настроить, чтобы собирать три бинарника из одного проекта, а потом делать из них один архив. И очень гибкий с поддержкой скриптов во всех полях.

1. 

   steban

   04.01.2017 06:30

   #9995498

   Оно в ядре и не нужно. Это можно быстренько сделать на коленке. Можно использовать s3 или просто машинку с openssh. В моем случае этим целям служит отдельный контейнер с caddy (+ модуль upload)
   

   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
   

   
   

   
   

   1. 

      steban

      12.01.2017 23:53

      #10010380

      А вот еще решение с хранением кеша на выполняющем хосте: https://github.com/Drillster/drone-volume-cache
      Но оно требудет привилегированного контейнера и подписанного drone.yml