Настройка CI в GitLab .gitlab-ci.yml

23.12.2021 , Ristee 2

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

before start

Используемая версия gitlab — self-hosted 13.12.12
Runner — shell

Раннеры (runners)

Раннер (runner) — приложение с помощью которого будет разворачиваться наше приложение (здесь речь будет идти о shell, но в целом это справедливо и для других типов). Раннер устанавливается достаточно просто, через apt install, далее необходимо его зарегистрировать. Для этого необходимо запустить sudo gitlab-runner register далее необходимо ввести некоторые данные:

  1. GitLab URL (ex: gitlab.com)
  2. Токен раннера (на странице со списком раннеров будет доступен токен)
  3. Описание раннера
  4. Указать соотвествтующие необходимые для запуска тэги
    далее в настройках (с веб страницы) можно дополнительно установить запуск раннера без тэгов или с таковыми и т.п.

Запуск джобы без тэга

По-умолчанию все раннеры должны выполняться с тегами, тогда те джобы, которые без тегов будут ожидать необходимого раннера, gitlab укажет, что для джоба нет подходящего раннера. Чтобы избежать такой ситуации, можно установить флажок Run untagged jobs в настройках раннера и тогда можно запускать раннер (джобу) без тэга.

Тэги (tags)

Тэги — используемые метки для определения какой именно раннер будет использоваться.
Если для раннера установлены два тэга, то при выполнении job эти два тэга должны быть обязательно определены. Т.е. условние выполнения раннера обязательное присутствие всех тэгов раннера.

У тэгов есть минус, тэги не могут быть динамическими, хотя на сегодняшний день пропозал на эту тему висит (по крайней мере на версию 14, динамических тэгов ещё нет), для динамического определения тэгов, необходимо исхитриться, например путем сочетания наследования и условий (подробнее об этом в "Выбор тэгов в зависимости от ветки")

Пример:

job1_name:
    tags:
        - tag1
        - tag2

Стейджи (stages)

stage — этапы выполнения задач, в списке выполнения они будут разделены в вертикальные столбцы, этапы выполняются параллельно, но может быть установлена зависимость выполнения через зависимости от джобов

Наследование (extends)

Джобы могут быть скрытые и не скрытые, отличие: .job1 — скрытый, job2 — не скрытый, от скрытых можно наследоваться. В случае наследования все ключи переопределяются и будет использован последний. Так же при наследовании будут заменены и все массивы.
Есть второй вариант наследования — якори (anchors), который может быть использован более гибко.

before_script

Список команды, которые будут выполнены до основного списка команд (script)

after_script

Список команды, которые будут выполнены после выполнения основного списка команд (script)

.some_deploy:
    stage: deploy
    script:
        - command1
        - command2
special_deploy:
    stage: deploy
    tags:
        - runner1
    after_script:
        - doing thing

Зависимости (needs)

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

deploy_job:
    stage: deploy
    needs:
        - test_app

Правила (rules)

В зависимости от определенных ситуаций (в том числе от разных условий или значений переменных) можно использовать условия выполнения. В if можно сравнивать значения переменных с каким либо значением. Переменная должна быть определена до выполняемого джоба, если условие не выполняется, джоба даже не будет рассматриваться и не попадет в список выполняемых. if в rules имеет объединение типа "или". Чтобы объединить с помощью "и", условие можно объединить в одном if через && ($SERVERNAME == "server1" && $CI_COMMIT_BRANCH == "master")

deploy_server1:
    stage: deploy
    rules:
        - if: '$SERVERNAME == "server1"'

Важно: надо отметить, что нельзя использовать rules рядом с only или when

Сравнение веток

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

deploy_develop:
    stage: deploy
    rules:
        - if: '$CI_COMMIT_BRANCH == "develop"'

Выбор тэгов в зависимости от ветки

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

.update_server_template
    stage: update
    script:
        - commands

update_server_master:
    extends: .update_server_template
    tags:
        - server_master
    rules:
        - if: '$CI_COMMIT_BRANCH == "master"'

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

Запуск

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

Ручной запуск

Ручной запуск бывает когда:

  1. у джобы установлен ключ when: manual
  2. запустили все вручную, при этом можно определить переменные с определенным значением

Запуск для выбора чего-либо

Для запуска вручную с указанием необходимых переменных и их значений, заходим в Project > CI/CD > Pipelines , далее справа наверху кнопка Run pipeline, указываем какую ветку использоваться, указываем переменную окружения и её значение и запускаем. Теперь те джобы, в которых было условие, зависящее от указанной переменной окружения, будут выполнены.

Проверка правильности

Для правильности написания конфига у Gitlab есть CI Lint: Project > CI/CD > Pipelines — кнопка CI lint

Источники

Tags:

2 Replies to “Настройка CI в GitLab .gitlab-ci.yml”

    • Leave a comment

    Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.