6 создать в корневой папке gitlab проекта файл gitlab ci yml из шаблона android

Обновлено: 17.05.2024

Gitlab предоставляет уникальную возможность получить одновременно бесплатный приватный репозиторий и бесплатный CI/CD из коробки в том же месте. Для сохранения баланса он конфигурируется не менее уникальным способом через конфиг-файл, который не так-то просто для понимания(я в первый раз вникала чересчур долго). В конце концов разобралась, и хочу поделиться.

Есть файл .gitlab-ci.yml , который лежит в корне прое к та, в нем конфигурируется вся магия сборки. Если гитлаб видит, что в ветке есть такой файл, он запускает сборку по алгоритму, описанному в этом файле.
По дефолту билды запускаются на каждый пуш в ветку.
То есть если у вас в одной ветке нет конфига, а в двух других он принципиально разный, если запушить что-то новое в три ветки сразу, запустится два билда с разными алгоритмами.

Настроить билды без этого файла, как, например, в тимсити или дженкинсе нельзя.

В отличие от простого gh-pages, где ты собираешь, что хочешь, и просто пушишь в репозиторий файл index.html, тут так поступить нельзя. Ну, то есть, в теории, можно, но автоматически ничего все равно работать не будет.

Как будет выглядеть в gitlab конфиг “типа как на gh-pages” (я предполагаю, что мы, как и с gh-pages уже собрали все в папку dist и запушили ее).

Главный секрет деплоя статики — положить все необходимое в папку public и отметить ее как артефакт.

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

Простейший конфиг для сборки и деплоя статического сайта на gitlab

Все, мы разобрались с тем, как сделать, чтобы сайт собирался и деплоился, достаточно просто вносить изменения, пушить и он автоматически будет пересобираться и обновляться!

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

Конфиг “stage” — этап билда, по дефолту их три: build, test, deploy. Этапы всегда идут в четком порядке. Можно не указывать ничего, тогда запустится на этапе test.

Разберемся, что это такое и как использовать это во благо. Если подумать, этапов работы с кодом у нас и правда в целом три: собрать, протестировать(убедиться, что это можно деплоить), задеплоить. И если один из них упал, остальные запускать нет необходимости.

По этому принципу делает и гитлаб:

  • jobs. Их может быть много разных. Каждая делает свое маленькое дело — собирает фронтенд с одним параметром, собирает с другим параметром, прогоняет тесты интерфейса, прогоняет линтер бекенда.
  • stages: это этапы сборки. Внутри одного этапа все jobs выполняются без определенного порядка. Однако по умолчанию джобы следующего этапа не стартуют, пока все из предыдущего не завершились успешно
  • pipelines — pipeline создается каждый раз при пуше или если запустить его руками. Один пайплайн — одна сборка с конкретной кофнигурацией stages и jobs.

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


один пайплайн, три стейджа, шесть джоб. три англицизма

Например кусочек конфига для скриншота выше:

Стоит поменять порядок этапов в конфиге, и они начнут выполняться в другом порядке.

Билды обычно идут дольше, чем хотелось бы. Первое, что приходит в голову — это что же, каждый раз скачивать зависимости? Это можно улучшить!

В конфиг задачи достаточно добавить вот такое:

$ – переменная окружения, которую создает гитлаб. В ней хранится хеш имени ветки, в которой запущен процесс.

Это будет работать следующим образом: каждый раз при запуске задачи гитлаб будет искать у себя сохраненный кеш с названием, совпадающим с cache-for-my-task-хеш_ветки . Если найдет — скачает его и добавит к кодовой базе, на которой будут совершаться дальнейшие действия.
В данном случае скачает все node_modules, которые сохранились с предыдущего запуска и после выполнения стандартного шага npm i установка зависимостей произойдет гораздо быстрее.

Гитлаб предоставляет много разных переменных, которые можно использовать здесь. Кешировать node_modules наиболее эффективно по веткам, хотя можно шерить кеш на весь репозиторий. Или вообще написать хитрое условие.

В конфиге выше написано:

Артефакты работают так: файлы, лежащие по указанным путям, в конце каждой джобы загружаются на сервер гитлаба и скачиваются в начале каждой джобы следующего этапа.

Погодите, звучит как кеш! В чем разница?

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

  • У кеша мы можем указать ключ, а у артефактов — не можем. Это происходит потому, что кеш шарится между несколькими пайплайнами, можно запустить сборку ветки два раза, и они будут использовать один и тот же кеш (потому что название ветки, на которое мы ссылаемся в ключе — одинаковое).
    А артефакт живет только внутри одного пайплайна и все, причем передается только из этапа в этап, не между джобами одного этапа.
  • Артефакт можно скачать из интерфейса гитлаба — все пакуется в zip и доступно для скачивания и анализа (удобно дебажить проблемы с node_modules). У кеша такой опции нет. Если смотреть чуть глубже, то кеш хранится на там, где установлен раннер, а артефакт — у самого гитлаба. Это как раз и обеспечивает гарантию наличия/отсутствия кеша и артефактов. Кстати, можно настроить и хранить артефакты до 30 дней.

Я описала два глобальных отличия, есть еще несколько, их можно найти здесь.

Но в итоге непонятно: как тут добавление артефактов позволяет деплоить pages, и когда вообще нужно их использовать?

  • Деплой pages происходит просто потому, что гитлаб придумал такой алгоритм — если в артефактах папка public — она используется для раздачи статики. Вот и вся хитрость
  • Артефакты же нужно использовать когда нужно передать какие-то данные между этапами сборки. Например, в одном этапе собрали бандл фронтовый, и в качестве артефакта передали его на этап деплоя.

Все, базовые основы CD на gitlab вы знаете, теперь можно хостить и деплоить код втайне от подписчиков на гитхабе (а если не хотите и гитлаб светить, то приватные репозитории + heroku в помощь!).

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

Итак, приступим.
С точки зрения GitLab, CI состоит из

  • Jobs, которые описывают что сделать. например, собрать код или протестировать
  • Stages, которые определяют когда стартовать Job-ы, например, стадия тестирования

Всю эту информацию о jobs и stages нам нужно передать GitLab-у. Сделаем мы это с помощью файла .gitlab-ci, который положим в корне проекта. В нем будут описаны все шаги, а также выполнятся необходимые скрипты.

Во-первых укажем образ, который будет выполнять Job

Затем в разделе под названием before_script напишем скрипты, которые сервер должен выполнить, чтобы настроить сборочное окружение.

Никакой магии здесь нет, и, если вы знакомы unix-системами, и их командами, то вам все должно быть понятно
Не забудьте указать номера версий SDK, которые сервер должен установить. Для этого перед блоком before_script добавьте

Далее, указываем типы этапов сборки в блоке stages

Теперь остается только указать как и где хранить артефакты, то есть apk:

Вот и все, а для релизной сборки укажем такой же блок, но stage и него будет deploy, а сборка будет собираться еще и с app:assembleRelease, и собираться такая сборка будет только при создании тэга в GitLab.

Дополнительно нам нужно настроить автоматическое инкрементирование номеров сборок
Для этого в Ваш build.gradle добавьте функции, которые будут генерировать versionCode и versionName на основе минимальной версии target api

Естественно, в корневом build.gradle у вас должны быть прописаны номера версии в виде

// Этот метод получает номер сборки из специального файла, который мы генерировали выше в скрипте .gitlab-ci
def getBuildNumberFromFile()

Остается вызывать этот метод для названия версии, а также для номера сборки

Готово с кодом, теперь нужно добавить переменную в GitLab, идея взята отсюда

Заходим в Settings->CI/CD->Variables, далее добавляем две переменные BUILD_NUMBER и CI_PIPELIBE_ID_TOKEB



BUILD_NUMBER присваиваем 1, а в CI_PIPELIBE_ID_TOKEB положим значение токена, который нужно сгенерировать через раздел Access Tokens профиля

Остается запушить изменения в GitLab, и он автоматически будет стартовать Pipeline
Для создания релизной сборки, которую мы настроили выше, нужно создать Тэг через Repository->Tags-> New Tag
Выбираете ветку, из которой хотите создать сборку и запускаете. Все готово!

1 комментарий


В статье решается задача управления описанием сборки для большого количества однотипных приложений. Чтобы в проекте заработал GitLab CI, нужно в репозиторий добавить файл .gitlab-ci.yml . Но что, если в сотне репозиториев это файл с одинаковым содержимым? Даже если разложить его по репозиториям один раз, то как его потом изменять? А что, если одного .gitlab-ci.yml мало для сборки — нужны Dockerfile или Dappfile , разные скрипты и структура YAML-файлов для Helm? Как обновлять их?

С чего начать решение задачи по сборке сотни однотипных приложений? Конечно же, посмотреть, можно ли GitLab CI указать использовать .gitlab-ci.yml из другого репозитория или компоновать .gitlab-ci.yml из файлов в других репозиториях…

В поисках такой возможности сразу всплывают следующие issues:

  1. В include надо указывать, из какой ветки брать файл для подключения, поэтому сборка не будет воспроизводиться.
  2. В include надо указывать, из какой ветки брать файл для подключения, поэтому нужно кэшировать эффективный .gitlab-ci.yml , хранить его и пересобирать уже на основе него.
  3. В некоторых проектах нужно решить пункт 1, а в некоторых — пункт 2, однако они взаимоисключающи.
  4. Если в подключаемом файле что-то поменялось, то по сути изменяется .gitlab-ci.yml того проекта, который собирается, но истории изменений не будет видно.
  1. Проблема с сотней одинаковых .gitlab-ci.yml остаётся.
  2. Проблема с обновлением дополнительных файлов тоже остаётся.

Взгляд под другим углом

Решение с include — это pull-модель, т.е. проект при сборке вытягивает часть конфигурации CI. Если заменить pull на push, то получится так:

  • создаётся проект common-ci-config, в котором хранится общий .gitlab-ci.yml и другие файлы, необходимые для сборки;
  • создаётся пользователь gitlab-ci-distributor, которому даются права на push (Master) в нужные проекты.

Для файлов сборки можно выбрать: либо добавлять их в коммит, либо в .gitlab-ci.yml у проектов, в задачу сборки, добавить git clone проекта common-ci-config.

Плюсы такого подхода:

  • В каждом проекте становится видно, когда изменился .gitlab-ci.yml и кто его изменил. Пропадает проблема хранения эффективного .gitlab-ci.yml , т.к. в каждом проекте всегда видно полную версию без include.
  • В проектах, где не нужна последняя версия сборочных файлов на момент сборки, сборочные файлы добавляются коммитом.
  • В проектах, где на момент сборки всегда нужна последняя версия, сборочные файлы клонируются.
  • Можно часть файлов добавлять в коммит, а часть — использовать из клонированной копии.
  • Можно реализовать концепцию include для .gitlab-ci.yml с помощью вызова скрипта. То есть, если нужно, чтобы .gitlab-ci.yml при сборке всегда использовал последнюю версию конфигурации тестирования, то тестирование выносится в скрипт в проекте common-ci-config.

GitLab API

Итак, проблема обозначена и есть вариант решения. Для продолжения нужно рассказать о GitLab API (документация на сайте GitLab). Понадобятся следующие методы:

Для вызова методов понадобится создать access token. Об этом будет дальше в статье, а пока — пример того, как получать список проектов в группе:

Настройка GitLab

Вызов методов API невозможен без авторизации. GitLab предлагает авторизацию через access tokens. Чтобы получить такой токен, нужно создать отдельного пользователя, которому будут даны права на управление нужными репозиториями. Пусть это будет пользователь gitlab-ci-distributor:



Далее нужно стать этим пользователем и создать access token:


Для доступа к проектам, где нужно управлять сборочными файлами, нужно добавить пользователя gitlab-ci-distributor в группу:


Общие для проектов файлы будут храниться в проекте сommon-ci-config. Проект нужно создать в отдельной группе — например, infra. В настройках проекта добавляется секретная переменная со значением полученного токена:


Описанные действия выполняются администратором один раз. Далее вся настройка производится через файлы в репозитории common-ci-config.

Репозиторий common-ci-config

Теперь можно протестировать работу с API через GitLab CI. Для этого в проект common-ci-config добавляется простой .gitlab-ci.yml :


… и скрипт distribute.sh , который пока покажет информацию о коммите и проекты из выбранной группы:


Результат выполнения задания distribute:

Доработка скрипта distribute.sh

Скрипт будет распространять общий файл .gitalb-ci.yml . Чтобы не путать его с .gitlab-ci.yml проекта common-ci-config, файл расположен в директории common . В файле описывается простое автоматическое задание:


Результат выполнения задания distribute:


В проекте group-of-alike-projects/project-pasiphae коммит будет выглядеть так:


Результат выполнения задания build в проекте group-of-alike-projects/project-pasiphae:


Видно, что пользователь, который запускает задание, — gitlab-ci-distributor. Но при этом автор коммита — пользователь, который сделал коммит в common-ci-config.

Отключение одновременной автоматической сборки


Внимание! Переменная GITLAB_USER_NAME появилась в GitLab 10.0 (релиз от 22 сентября 2017). В более ранних версиях есть только GITLAB_USER_ID и для условия придётся использовать ID пользователя. Этот ID можно узнать, например, выполнив задание со script: [export] или с таким запросом к API:


Если запустить это задание ещё раз, но от обычного пользователя, то всё выполнится успешно:


Заключение

В целом данной информации достаточно для того, чтобы дальше самостоятельно экспериментировать с массовым управлением проектами.

При разработке решения использовались следующие ресурсы:

Если вы используете Git и GitLab для хранения кода, то можете упростить и автоматизировать разворачивание вашего кода на сервере сразу же, при появлении новых изменений в GitLab репозитории. Этот процесс называется CI/CD (Continuous Integration, Continuous Delivery или Непрерывная интеграция и доставка). С помощью этой технологии вы можете выполнять тесты, собирать проект, а затем помещать результат сборки или исходники в нужное место.

В этой небольшой статье будет рассмотрена настройка GitLab CI CD для небольшого проекта на PHP без сборки и тестов, а только с копированием исходников в директорию веб-сервера на сервере проекта.

Настройка GitLab CI/CD

1. Установка GitLab Runner

Для того чтобы у GitLab был доступ к серверу, на этот сервер необходимо установить службу gitlab-runner. Именно эта программа будет забирать новые исходники с GitLab, выполнять с ними нужные действия и разворачивать на сервере. Установить её в Ubuntu можно из официальных репозиториев. Сначала добавьте репозиторий в систему:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

Обратите внимание, что поддерживаются Ubuntu 16.04, 18.04 и 20.04, если у вас другая версия, после установки репозитория вам надо будет изменить его на версию для ближайшего поддерживаемого дистрибутива. После этого можно установить пакет:

sudo apt install gitlab-runner

Так выполняется установка GitLab runner Ubuntu. В CentOS и других Red Hat дистрибутивах процедура установки похожая. Сначала добавьте репозиторий:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash


Затем установите пакет:

sudo yum install gitlab-runner


Возможно, в будущем процедура или ссылки на пакеты изменятся. Смотрите официальную документацию.

После установки запустите сервис с помощью systemd и добавьте его в автозагрузку:

sudo systemctl enable --now gitlab-runner

Откройте репозиторий на GitLab, для которого вы хотите настроить CI/CD, затем кликните по шестеренке (пункт Settings) в меню, а потом выберите CI/CD:


Возле пункта Runners нажмите кнопку Expand:


Общие раннеры от GitLab можно отключить для того чтобы они вам не мешали и не забирали задачи у вашего раннера. Для этого под надписью Enable shared runners for this project установите значение выключателя в положение выключено:


Необходимая вам информация находится в левой части окна, в разделе Specific runners. Тут вам надо узнать URL сервиса и токен авторизации, с которым вы будете регистрировать раннер:


Теперь возвращайтесь на сервер, на котором был установлен runner и выполните такую команду:

sudo gitlab-runner register

Программа спросит URL и токен, которые вы узнали на GitLab.


Затем надо ввести описание и теги для раннера. Теги будут использоваться в будущем для того чтобы отправлять этому раннеру задания. Далее останется только выбрать способ выполнения команд. Для того чтобы просто запускать командную оболочку можно выбрать shell.


Обратите внимание, что команду надо выполнять именно с sudo. Поскольку демон выполняется от имени пользователя root, то и авторизацию нужно выполнять от имени этого пользователя, иначе работать не будет, но и ошибок не выдаст.

Для того чтобы убедится, что всё настроено и работает нормально выполните такую команду:

sudo gitlab-runner verify


3. Настройка GitLab Runner


Кликните по значку карандаша (Edit) возле раннера и выставьте такие настройки:

  • Active - должно быть включено, иначе раннер не сможет выполнять задания;
  • Protected - должно быть включено, для того чтобы раннер брал задания из всех веток, а не только защищённых;
  • Run untagged jobs - должно быть включено, позволяет раннеру брать задачи без тегов;
  • Lock to current projects - если включено, этот раннер доступен только для этого проекта.

Все остальные опции можно не трогать.


После завершения настройки на забудьте нажать кнопку Save Changes. Дальше можно переходить к созданию файла .gitlab-ci.yml.

4. Создание gitlab-ci.yml

Именно в этом файле описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то на главной странице проекта нажмите кнопку Setup CI/CD:


После этого кликните по кнопке Create New CI/CD Pipeline:


Дальше перед вами откроется редактор файла .gitlab-ci.yml.


Как и следует из расширения - это файл в формате YAML, поэтому отступы перед значениями очень важны. Сразу же можете удалить отсюда все комментарии. Структура файла примерно такая:

Раздел stages описывает этапы разворачивания приложения и очередность их выполнения. Затем описываются задачи, которые будут выполняться в рамках каждого этапа. У задачи должен быть указан этап: stage и script со списком команд, которые будут выполняться на сервере. Во время разворачивания gitlab-runner автоматически создает на сервере (по умолчанию в домашней папке) директорию build, клонирует туда свежие исходники проекта и переходит в папку с исходниками. А дальше с помощью команд в секции script вы можете делать всё, что нужно с этими исходниками.

Для этого примера можно оставить только секцию deploy. Самый простой конфигурационный файл будет выглядеть вот так:

stages:
- deploy
deploy-job:
stage: deploy
script:
- echo "Deploying application. "
- echo "Application successfully deployed."

Сохраните этот файл. Для этого пролистайте вниз страницы и нажмите кнопку Commit Changes.

5. Проверка работы Pipeline

Если всё было сделано правильно, то ваш раннер получит эту задачу, склонирует исходники и выведет две строчки в терминал. Для того чтобы убедится что это всё произошло, в боковом меню выберите значок ракеты (CI/CD) а затем Pipelines:


Здесь отображаются все задачи CI/CD. В данном случае у вас должна быть одна задача.


Если всё прошло успешно перед ней будет зеленая кнопка Passed. Для того чтобы посмотреть лог выполнения задачи, кликните по этой кнопке, а затем выберите непосредственно задачу из списка:


В результате откроется лог выполнения раннера для этой задачи:

Поскольку внизу зелёным написано Job succeeded, значит задача выполнилась успешно. В самом верху лога вы можете видеть какой раннер использовался для выполнения, убедитесь, что это именно ваш раннер, а не один из стандартных.

6. Разворачивание исходников

Программа уже скачивает исходники на сервер, но дальше вы можете сделать с ними всё что хотите. Настраивать раннер загружать исходники прямо в папку веб-сервера не стоит, программа для этого не предназначена. Для копирования исходников лучше использовать rsync. Эта утилита позволяет копировать только изменившиеся файлы. Например, для копирования файлов из репозитория в /var/www/project необходимо добавить такую команду в секцию script:

rsync -av --no-perms --no-owner --no-group --exclude ".git*" $CI_PROJECT_DIR/ /var/www/project


Для редактирования файла .gitlab-ci.yml можете воспользоваться пунктом меню CI/CD -> Editor или найти и отредактировать этот файл в списке файлов. Папка, в которую вы собираетесь разврачивать проект должна существовать на сервере и у пользователя gitlab-runner должны быть права на запись в неё:

sudo mkdir -p /var/www/project

sudo chown gitlab-runner:gitlab-runner /var/www/project


Если всё было сделано верно на этот раз, то файлы появятся в папке:


Аналогичным образом вы можете добавлять другие команды, которые необходимо выполнить с исходниками на сервере. Можно даже загружать их на другие сервера с помощью того же rsync. Вообще говоря, локально можно было бы и обойтись без этой утилиты и воспользоваться cp. Но rsync позволяет именно синхронизировать изменения, что очень удобно.

Выводы

Теперь вы знаете как выполняется настройка GitLab CI CD, а также GitLab-runner. Как видите, это довольно полезные инструменты. Теперь на сервере будут оказываться все новые коммиты и у вас больше не будет необходимости выгружать их туда вручную.

Нет похожих записей


Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Читайте также: