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-образа с проектом на ревью (автоматический режим) и продакшн (ручной режим);
• остановка и удаление контейнеров, которые использовались для сборки проекта.

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

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