в GitLab

GitLab CI: Часть 3, введение в .gitlab-ci.yml


В одной из предыдущих статей мы полностью подготовили фундамент для использования GitLab CI, во второй успешно зарегистрировали раннер (runner), который будет заниматься выполнением инструкций из специального файла .gitlab-ci.yml.

В третьей статье цикла мы подробнее рассмотрим процесс continuous integration в GitLab и разберемся с простым примером конфигурационного файла .gitlab-ci.yml!

Итак, просесс continuous integration (CI) в GitLab работает следующим образом:

  • выполняется push изменений в репозиторий проекта;
  • если в корне проекта есть файл .gitlab-ci.yml, то GitLab понимает, что для этого проекта нужно использовать continuous integration;
  • GitLab ищет запущенный runner, подключенный для этого проекта (или общедоступный, shared runner);
  • GitLab передает файл .gitlab-ci.yml раннеру, который обновляет исходники в своем каталоге для билда (--builds-dir) и выполняет команды, описанные в этом файле;
  • после выполнения команд раннер возвращает в GitLab результаты, которые можно посмотреть рядом с соответствующим коммитом, на вкладке pipelines или вкладке jobs.

Простейший файл .gitlab-ci.yml (не выполняет полезных действий, но важен для понимания) может выглядеть так:

before_script:
    - uname -a 
job1:
  script:
    - php -v
job2:
  script:
    - php -v

или так:

stages:
  - test
  - deploy

test_job:
  stage: test
  script:
    - ansible-lint playbook.yml
    - ansible-playbook --check playbook.yml

  tags:
    - ansible

deploy_job:
  stage: deploy
  script:
    - ansible-playbook playbook.yml

  tags:
    - ansible

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

Подготовим «скелет» для нашего файла .gitlab-ci.yml — для начала опишем этапы и задачи, которые мы хотим реализовать с его помощью:

image: registry.gitlab.lc:5000/develop/ed:tmaier-dc-ssh
services:
  - registry.gitlab.lc:5000/develop/ed:my-docker-dind

variables:
  DOCKER_DRIVER: overlay

stages:
  - spawn
  - build
  - test
  - release
  - deploy
  - cleanup

spawn_containers:
  stage: spawn
  script:
    - echo "Start docker-containers for compile sources"

compile:
  stage: build
  script:
    - echo "Compile sources"

testing:
  stage: test
  script:
    - echo "Testing"

release-image:
  stage: release
  script:
    - echo "Build docker-image with sources"

deploy-to-review:
  stage: deploy
  script:
    - echo "Deploy docker-image with sources to rewiew"

deploy-to-prod:
  stage: deploy
  script:
    - echo "Deploy docker-image with sources to production"
  when: manual

cleanup:
  stage: cleanup
  when: always
  script:
    - echo "Stop & remove containers"

Итак, в данном примере мы включаем в .gitlab-ci.yml специальные образы, которые подготовили в предыдущей статье и описываем шесть этапов (stages), а именно:

  • запуск контейнеров, которые будут использоваться для сборки проекта;
  • выполнение действий по сборке проекта;
  • тестирование собранного проекта;
  • «упаковку» собранного и протестированного проекта в docker-образ;
  • деплой docker-образа с проектом на ревью (автоматический режим) и продакшн (ручной режим);
  • остановка и удаление контейнеров, которые использовались для сборки проекта.

Также следуется отметить, что данные этапы выполняются последовательно и зависят друг от друга — если, например, этап сборки проекта завершится с ошибкой, то этап тестирования (и следующие за ним) просто не запустится.

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

Добавить комментарий