Comments 15
Правильно ли я понял, что CI в таком варианте, по сути, настраивается для одного репозитория? Зависимости от нескольких репозиториев можно сделать?
Как дела обстоят с шаблонами? Допустим, у меня несколько контуров тестирования, девеоперский и продакшн, и все нужно собирать похожим образом с похожим наборов параметров. Удастся ли тут легко организовать такую схему?
Возможно, глупый вопрос, но все же — Python скрипты можно пускать в шагах сборки?
Как дела обстоят с шаблонами? Допустим, у меня несколько контуров тестирования, девеоперский и продакшн, и все нужно собирать похожим образом с похожим наборов параметров. Удастся ли тут легко организовать такую схему?
Возможно, глупый вопрос, но все же — Python скрипты можно пускать в шагах сборки?
- Настраивается не только для одного репозитория, но и если необходимо для каждой отдельной ветки.
- Шаблонов вроде пока еще не завезли, но разные джобы на разные окружения завести довольно просто, как и описано в статье
- В джобе есть такой раздел script: и в нем вы можете прописать любую последовательность команд, вы бы делали в терминале, если бы собирали ручками. Соответственно для запуска каких либо скриптов, скорее всего достаточно подключить docker-image с необходимыми зависимостями.
А вообще кроме этой статьи еще советую прочитать на ту же тему блог гитлаба https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/
Так же есть отличная статья по ознакомлению с GitLab CI и понятию CI в целом.
На своей работе используем gitlab, в частности gitlab-CI.
> Допустим, у меня несколько контуров тестирования, девеоперский и продакшн, и все нужно собирать похожим образом с похожим наборов параметров. Удастся ли тут легко организовать такую схему?
Да, это делается достаточно легко. Помимо этого, возможно создать зависимости, например, если промежуточные тесты не проходят, CI-сервер даже не будет приступать к продакшн тестам.
> Python скрипты можно пускать в шагах сборки?
Конечно. На компьютере, который играет роль сервера, можно развернуть runner, который будет выполнять написанные сценарии либо в некой виртуальной машине, контейнере Docker, либо же в обычной командной строке (как cmd, так и bash).
> CI в таком варианте, по сути, настраивается для одного репозитория?
Верно, в каждом репозитории лежит свой файл сценария сборки и тестирования.
> Зависимости от нескольких репозиториев можно сделать?
Смотря что вы имеете в виду под зависимостями. Зависимость от успешной сборки другого, нигде не указанного репозитория? Зависимость от подмодуля?
P.S. Писал в личный блог пост по применению этой системы для сборки C++ проектов для Visual Studio и ARM DS-5. Если сообществу будет интересно, приведу в более приемлемый для хабра вид и опубликую.
> Допустим, у меня несколько контуров тестирования, девеоперский и продакшн, и все нужно собирать похожим образом с похожим наборов параметров. Удастся ли тут легко организовать такую схему?
Да, это делается достаточно легко. Помимо этого, возможно создать зависимости, например, если промежуточные тесты не проходят, CI-сервер даже не будет приступать к продакшн тестам.
> Python скрипты можно пускать в шагах сборки?
Конечно. На компьютере, который играет роль сервера, можно развернуть runner, который будет выполнять написанные сценарии либо в некой виртуальной машине, контейнере Docker, либо же в обычной командной строке (как cmd, так и bash).
> CI в таком варианте, по сути, настраивается для одного репозитория?
Верно, в каждом репозитории лежит свой файл сценария сборки и тестирования.
> Зависимости от нескольких репозиториев можно сделать?
Смотря что вы имеете в виду под зависимостями. Зависимость от успешной сборки другого, нигде не указанного репозитория? Зависимость от подмодуля?
P.S. Писал в личный блог пост по применению этой системы для сборки C++ проектов для Visual Studio и ARM DS-5. Если сообществу будет интересно, приведу в более приемлемый для хабра вид и опубликую.
Как найти
Пока можно прогуглить по фразе «Автоматизированная сборка C++ проектов в Gitlab CI»
Все build steps указываються в .gitlab-ci.yml, который лежит в корне репозитория и да — для одного репозитория.
В .gitlab-ci.yml можно указывать enviroments, которые можно настроить в настройках проекта ( pipelines ), соответсвенно конфигурация может меняться, в зависимости от того, для какого енва ты билдишь и куда деплоишь.
Можно запускать все что угодно — главное, что бы на машине, на которой раниться gitlab-runner были все необходимые компоненты.
Мы используем собранный под себя имейдж докера с нодой и некоторыми другими инструментами для билда. И все инструкции описанные в .gitlab-ci.yml выполняются в этом контейнере.
В .gitlab-ci.yml можно указывать enviroments, которые можно настроить в настройках проекта ( pipelines ), соответсвенно конфигурация может меняться, в зависимости от того, для какого енва ты билдишь и куда деплоишь.
Можно запускать все что угодно — главное, что бы на машине, на которой раниться gitlab-runner были все необходимые компоненты.
Мы используем собранный под себя имейдж докера с нодой и некоторыми другими инструментами для билда. И все инструкции описанные в .gitlab-ci.yml выполняются в этом контейнере.
Отличная, на мой взгляд статья. Хорошая альтернатива Jenkins-у.
Как-то, на уровне подсознания, инструкции установки вида «curl некий_магический_скрипт | bash» вызывают недоверие.
Мы у себя рассматривали gitlab-ci как альтернативу jenkins для сборки .net проекта. На текущий момент как ci он нормально работает, но есть пару моментов:
— нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
— сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
В результате как cd его пока использовать сложно.
Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
— нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
— сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
В результате как cd его пока использовать сложно.
Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц
Как вариант — в одной из последних версий gitlab'a появились блокировки на файл. Какой-нибудь team-lead или deploy-manager лочит на себя этот файл — и все остальные лишаются возможности редактировать этот файл.
Учитывая, как развивался GitLab в последнее время, легко можно запросить такую фичу.
На счет безопасности, в некоторых CI есть интересная встроенная защита от таких случаев.
Пошло от Travis CI, по-моему, Например, как это реализовано в drone.
Переменные зашифровывают и заливают в корневую папку вместе с сигнатурой на файл конфигурации.
Поэтому если файл изменится CI откажется подставлять зашифрованные переменные в эту сборку.
Возможно и в Gitlab CI есть нечто подобное.
Пошло от Travis CI, по-моему, Например, как это реализовано в drone.
Переменные зашифровывают и заливают в корневую папку вместе с сигнатурой на файл конфигурации.
Поэтому если файл изменится CI откажется подставлять зашифрованные переменные в эту сборку.
Возможно и в Gitlab CI есть нечто подобное.
Посмотрите http://docs.gitlab.com/ce/ci/yaml/README.html#stages
Manual actions
возможно это то, что вам нужно.
Ограничения по изменениям — можно просто административно. Если этого недостаточно — завести отдельный репозиторий из которого будет делаться публикация (и для этого репозитория прописать шаг запуска публикации).
Для этого же спец. репозитория заданы переменные, необходимые для публикации (ключи доступа на сервер например), без которых публикация невозможна.
В этом случае разработчик не сможет путем локальных изменений что-то опубликовать, т.к. доступа к спец. репозиторию не имеет.
Manual actions
возможно это то, что вам нужно.
Ограничения по изменениям — можно просто административно. Если этого недостаточно — завести отдельный репозиторий из которого будет делаться публикация (и для этого репозитория прописать шаг запуска публикации).
Для этого же спец. репозитория заданы переменные, необходимые для публикации (ключи доступа на сервер например), без которых публикация невозможна.
В этом случае разработчик не сможет путем локальных изменений что-то опубликовать, т.к. доступа к спец. репозиторию не имеет.
Если будут использоваться самоподписные сертификаты, то на стороне docker-daemon, с которого будет проходить вся работа с образами нужно выставить опцию --insecure-registry, в противном случае при попытке залогинится — мы получим ошибку (раннеров тоже касается).
Как насчет добавить самоподписанный сертификат в список корневых?
Sign up to leave a comment.
Gitlab-CI